Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2017

1 participants
62 discussions

ffmpeg-devel.log.20170305
by burek 06 Mar '17

06 Mar '17

[08:44:16 CET] <fritsch> wm4: when implementing a hw decoder and this one is then used by the send / receive API and let's consider both send and receive return EAGAIN - cause everything is filled up but we don't receive data yet. How would you handle that, so that we don't run into an endless high cpu intensive loop? [10:25:32 CET] <nevcairiel> fritsch: decode APIs are not allowed to return EAGAIN [10:25:55 CET] <nevcairiel> (unless noblock flag is set, in which case its up to the c aller to figure out what to do) [10:32:25 CET] <fritsch> nevcairiel: but what to do if it cannot take any pakets anymore, but is not yet read to output something? [10:32:35 CET] <nevcairiel> wai [10:32:37 CET] <nevcairiel> t [10:32:42 CET] <nevcairiel> or buy hardware that behaves properly [10:32:46 CET] <fritsch> haha [10:33:07 CET] <fritsch> not sure what that has to do with the hardware [10:33:19 CET] <fritsch> think of 120 fps hevc10 bit content with unbelievably high bitrate [10:33:38 CET] <fritsch> in the sense of decoding takes long, but all buffers are already in [10:33:42 CET] <fritsch> do I overlook something? [10:34:14 CET] <nevcairiel> the decoder would then need to wait and block internally [10:34:48 CET] <nevcairiel> the API does not allow for returning EAGAIN [10:36:21 CET] <fritsch> mmh, then the docu is wrong [10:36:35 CET] <fritsch> ah no it's not - but it's not 100% clear [10:36:49 CET] <nevcairiel> it has specific cases where it returns EAGAIN, ie. it wants more inpuit [10:36:55 CET] <fritsch> jep, figured [10:37:10 CET] <fritsch> so if there is no error, no input needed, it needs to block [10:37:11 CET] <fritsch> okay [10:37:51 CET] <fritsch> thx very much [12:10:10 CET] <wm4> nevcairiel: what noblock flag [12:10:44 CET] <wm4> fritsch: it can't return eagain for both... it must implement waiting to prevent that [12:10:56 CET] <nevcairiel> probably there isnt even such a flag on avcodeccontext [12:11:03 CET] <nevcairiel> formatcontext has it, i guess [12:11:56 CET] <wm4> fritsch: we could implement an optional async mode, but even then you'd need a callback or whatever to notify the api user of progress [12:12:32 CET] <wm4> fritsch: what I definitely want to avoid is that the api user has to poll/sleep - that would be crap [13:21:28 CET] <cone-200> ffmpeg 03Michael Niedermayer 07master:fab13bbbcdf9: avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: 134527392 * 16 cannot be represented in type 'int' [13:21:29 CET] <cone-200> ffmpeg 03Michael Niedermayer 07master:d03d38616278: avcodec/wavpack: Check bitrate_acc for overflow [13:21:30 CET] <cone-200> ffmpeg 03Michael Niedermayer 07master:29638d4db90d: avcodec/dcadsp: Fix 2 runtime error: signed integer overflow: -1958094138 - 1078906344 cannot be represented in type 'int' [13:21:31 CET] <cone-200> ffmpeg 03Michael Niedermayer 07master:ba150051322c: avcodec/wavpack: Fix runtime error: left shift of negative value -2 [14:41:19 CET] <cone-200> ffmpeg 03Carl Eugen Hoyos 07master:1638d956a35c: lavf/matroska: Support QDMC. [15:49:50 CET] <BtbN> philipl, could you have a look at https://github.com/BtbN/FFmpeg/commit/master ? I have mostly rewritten the crop/resize patch, and in my tests it works as expected. Would just like a second pair of eyes for logic errors. [16:04:45 CET] <BtbN> oh hey, VS2017 has a language setting, that even the commandline tools follow [16:06:08 CET] <JEEB> nice [16:20:26 CET] <BtbN> great, while compiling, Windows Defender uses more CPU than all compiler processes combined [16:20:34 CET] <BtbN> Lets turn that shit off [16:25:31 CET] <BtbN> "built with Microsoft (R) C/C++ Optimizing Compiler Version 19.10.24930 for x64" hey, that just worked [16:26:33 CET] <JEEB> yayifications [16:28:16 CET] <jamrial> BtbN: just add a your msys or cygwin environment folder to the exception list [16:28:28 CET] <BtbN> hm? [16:28:36 CET] <BtbN> Oh [16:28:38 CET] <BtbN> nah [16:28:51 CET] <durandal_1707> BBB: have you looked at vmaf patch? [16:35:26 CET] <jamrial> that mail has probably the longest subject ever [16:36:56 CET] <Compn> does mail rfc have a limit on subject length ? [16:37:45 CET] <durandal_1707> yes, to loong and devs ignore it [16:38:07 CET] <kierank> vmaf is weird metric, ask BBB [16:40:33 CET] <cone-200> ffmpeg 03Paul B Mahol 07master:035e932d7c03: avformat/vivo: fix logic error in checking version in probe [17:07:45 CET] <nevcairiel> BtbN: you should've waited 2 days when 2017 final comes out :d [17:08:55 CET] <JEEB> oh, it's that close? nice [17:09:03 CET] <JEEB> I should really move to VMs with VS... [17:09:12 CET] <JEEB> I've got 2010,2013,2015 installed on this host OS now [17:09:27 CET] <nevcairiel> 2017 finally provides a modern no-frills installer [17:09:35 CET] <nevcairiel> it should install much quicker and actually uninstall without troubles [17:09:38 CET] <BtbN> nevcairiel, I'm pretty sure it just updates [17:12:44 CET] <nevcairiel> and yeah official release day is march 7th [17:13:10 CET] <BtbN> It didn't install into any special RC directory. So I'm pretty sure it will just self-update to the release version [17:14:53 CET] <nevcairiel> i guess i'll finally kill the 2012 fate system then and replace it with a 2017 [17:15:12 CET] <JEEB> sounds like a good idea, only game devs seem to have stayed with 2012 [17:17:38 CET] <kierank> BtbN: the problem is if you do scaling in your decoder that crazy guy has justification for doing it [17:17:49 CET] <kierank> irrespective of the fact yours is a black box [17:18:03 CET] <BtbN> the 9 dude? [17:18:25 CET] <nevcairiel> there is still a huge difference in adding hundreds of lines of unoptimized code and setting 2 flags for the hardware [17:18:35 CET] <kierank> i agree [17:18:38 CET] <kierank> but that guy won't [17:18:48 CET] <BtbN> That guy won't agree with anything sensible [17:18:49 CET] <nevcairiel> what do we care, its not like his code is getting in [17:19:08 CET] <kierank> you know as well as i do that because of the crazy decision making processes, that code will get in [17:19:26 CET] <BtbN> wm4, shouldn't the cuvid deinterlacing shenanigans work, now that the lazy filter init is in? [17:19:39 CET] <BtbN> I still need a "-r 50" input option for the output to double in framerate [17:20:13 CET] <BtbN> I doubt that his code will get in. I haven't seen anyone in favor for it. [17:31:52 CET] <wm4> BtbN: this never affected deint [17:31:56 CET] <wm4> but maybe scaling [17:32:12 CET] <BtbN> scaling/cropping works fine out of the box [17:32:23 CET] <BtbN> But it doubling the framerate is completely lost [17:32:42 CET] <BtbN> Maybe I should move that in front of the get_format callback as well? [17:32:56 CET] <wm4> I don't know if the decoder can even signal this (usually it wouldn't make sense) [17:35:00 CET] <nevcairiel> changing the time base from a decoder is just not something that any other thing does, so user-code probably doesnt check for a change there [17:36:33 CET] <nevcairiel> not to mention that the primary timebase is not even a f ield a decoder can access [17:37:34 CET] <nevcairiel> timestamps are supposed to be largely opaque for decoders [17:50:21 CET] <BBB> the vmaf patch subject needs some work, yes [17:50:35 CET] <BBB> as for the patch itself, the problem is it uses pipe/fork, so Im not 100% sure its appropriate [17:50:46 CET] <BBB> but theres no other way to interact with vmaf ATM, since it has no API that Im aware of [17:51:10 CET] <JEEB> yeah, it's just a tool with python implementation I think? [17:51:14 CET] <JEEB> it's not really meant to be used as a lib [17:51:53 CET] <BBB> ATM, yes [17:52:06 CET] <BBB> still cool to have it integrated even if the patch needs to be applied manually [17:52:12 CET] <JEEB> sure [17:52:20 CET] <BBB> I can see this being useful to e.g. youtube or so :) [17:52:29 CET] <BBB> anyway, the gsoc project is to integrate it for real [17:52:30 CET] <BBB> so [17:52:36 CET] <BBB> stuff2do [17:52:46 CET] <JEEB> yup [18:55:22 CET] <kierank> atomnuker: is referencing a frame of a different resolution in av-1 well defined? [18:57:22 CET] <kierank> ok found it in the spec, seems to be [18:57:42 CET] <nevcairiel> probably inherited that from vp9 [19:03:39 CET] <kierank> ah didn't know vp9 allowed tht [19:36:57 CET] <BBB> kierank: theres a spec? [19:41:03 CET] <adeel2> durandal_1707: I'm still getting these 3 errors: [xpm @ 0x7f7494007960] [IMGUTILS @ 0x7f749d4f7b80] Picture size 0x0 is invalid [xpm @ 0x7f7494007960] video_get_buffer: image parameters invalid [xpm @ 0x7f7494007960] get_buffer() failed how would I go on about fixing these? [19:42:00 CET] <durandal_1707> adeel2: by moving get buffer to right place [19:42:38 CET] <durandal_1707> get buffer needs width and height to be non zero [19:50:01 CET] <adeel2> durandal_1707: okay, got those errors fixed, now I'm getting Picture size 2147483648x2147483648 is invalid [19:50:17 CET] <JEEB> that is a cool picture size :P [19:50:37 CET] <durandal_1707> adeel2: you did something wrong [19:51:20 CET] <adeel2> I think it's an overflow issue [19:51:41 CET] <durandal_1707> adeel2: where you put this get buffer? [19:52:23 CET] <adeel2> durandal_1707: right after "ff_set_dimensions" in the beginning [19:52:51 CET] <durandal_1707> adeel2: before sscanf? [19:53:03 CET] <durandal_1707> use common sense [19:54:22 CET] <adeel2> lol. my bad. [20:11:59 CET] <adeel2> durandal_1707: I've tried skipping the dimension checking function. still get error in get buffer. have now called it afte sscanf [20:13:23 CET] <durandal_1707> adeel2: dunno, i need to see code [20:15:11 CET] <adeel2> https://github.com/adl1995/FFmpeg/commit/97465bd80da4eb20304eed90c61f589b7c… [20:17:04 CET] <unholy_me> @durandal_1707 is there any good audio filter in the avfilter, which has multiple channels? [20:17:23 CET] <unholy_me> as input* [20:18:29 CET] <durandal_1707> unholy_me: pan, sofalizer, stereotools [20:20:06 CET] <durandal_1707> adeel2: why you blindly copied xbm code without any unnderstanding? [20:20:45 CET] <durandal_1707> adeel2: there is already code in xpm which handles width and height [20:22:02 CET] <durandal_1707> unholy_me: for start just try to get compilation of filter and simple pass that returns unchanged frames [20:24:53 CET] <unholy_me> @durandal_1707 : I tried and compiled a simple image filter given in doc/writing_filters and understood how it works [20:25:22 CET] <unholy_me> If I ignore the math, i can write a very simple filter [20:26:00 CET] <durandal_1707> now modify it and do audio one [20:27:58 CET] <durandal_1707> the square decoder is very simple one [20:28:54 CET] <unholy_me> Thanks @durandal_1707 On it [20:34:01 CET] <unholy_me> @durandal_1707 I was thinking, the skip_spaces, parse_channel_name functions all remain the same right? [20:35:24 CET] <durandal_1707> no, you dont neeed any of pan code just structure [20:38:37 CET] <unholy_me> If I may, what exactly is the difference between a decoder and filter? [20:39:23 CET] <durandal_1707> unholy_me: decoder actually decompress something from compressed stream [20:39:52 CET] <unholy_me> and filter? [20:40:03 CET] <durandal_1707> ambisonic decoder doesnt have to decompress anything its just called that way [20:40:33 CET] <durandal_1707> filter just process input in any way it wants [20:41:22 CET] <durandal_1707> it doesnt do any compression and bitsttream format stuff [20:41:43 CET] <unholy_me> So, in the qualification task we are supposed to design a square decoder or a filter? [20:42:23 CET] <durandal_1707> unholy_me: square decoder as filter. its just naming [20:46:50 CET] <unholy_me> @durandal_1707 Also, what options would be there in the square filter? [20:47:04 CET] <unholy_me> Like to fill the option array [20:48:23 CET] <durandal_1707> unholy_me: name it ambisonic filter. square would be just output option [20:50:07 CET] <durandal_1707> it would accept numerous input formats in which ambisonic can be found in wild [20:50:34 CET] <durandal_1707> for now just concentrate on B format [20:51:29 CET] <unholy_me> B-format : W,X,Y,Z channels only? [20:52:11 CET] <durandal_1707> yes, thats most common ambisonic format [21:40:59 CET] <unholy_me> @durandal_1707 I don't understand what to write in query_format() ? [21:41:57 CET] <durandal_1707> unholy_me: requst 4 channels in input and 4 in output [21:43:26 CET] <durandal_1707> set channel layout [21:43:48 CET] <unholy_me> AVFilterLink *inlink <--- what is this set to? [21:44:23 CET] <durandal_1707> thats your input link [21:45:06 CET] <durandal_1707> you set to it channel layouts, samplerates and sampleformats [21:46:17 CET] <unholy_me> Then how do I request "4 channels" specifically? [21:46:31 CET] <unholy_me> I understand for 1 channel [21:46:41 CET] <durandal_1707> unholy_me: have you read doc/filters_design.txt? [21:47:15 CET] <durandal_1707> unholy_me: by signaling only 4 channel layout [21:48:46 CET] <unholy_me> okay okay... sorry [21:48:56 CET] <unholy_me> reading it now [22:09:45 CET] <unholy_me> @durandal1707 is it true that every channel has a series of frames? [22:10:13 CET] <unholy_me> how are frames designated for audio channels? [22:14:16 CET] <durandal_1707> unholy_me: every frame have channels [22:15:25 CET] <durandal_1707> depending on sample format how it is interleaved in frame array [22:50:13 CET] <unholy_me> AV_CH_LAYOUT_4POINT0 ---> is this the correct layout for the square filter? [22:51:51 CET] <durandal_1707> unholy_me: not important, just that it have 4 channels [22:52:25 CET] <unholy_me> aye, sir! [22:58:01 CET] <unholy_me> another thing, do we have to preset the channel layout or detect which channel layout is incoming? [22:59:29 CET] <durandal_1707> unholy_me: you receive ch layout which you signal in query formats [23:00:15 CET] <durandal_1707> one can accept multiple at once. but not in your case [23:01:33 CET] <unholy_me> There is a function to set channel layout right? Which directory can I find it? [23:03:04 CET] <durandal_1707> unholy_me: look at other filters and their query formats [23:09:34 CET] <unholy_me> \durandal_1707 the w,x,y,z would have a float value in every frame, right? [23:11:05 CET] <durandal_1707> unholy_me: no,they are sugned 16bit integers in wav, but you can request float as processing format for simplicity [23:14:42 CET] <unholy_me> also the angle theta, that would be a float? [23:16:01 CET] <durandal_1707> unholy_me: yes, but for square thats fixed [23:19:45 CET] <unholy_me> ohkay at 1.57 rad [23:24:55 CET] <unholy_me> would it be okay to take buffer in this? [23:28:46 CET] <durandal_1707> unholy_me: what? [23:29:25 CET] <unholy_me> Just buffer is ued when the frames are big, right? [23:30:43 CET] <durandal_1707> unholy_me: just process full frames. no need for extra buffers [00:00:00 CET] --- Mon Mar 6 2017

1 0

ffmpeg.log.20170305
by burek 06 Mar '17

06 Mar '17

[01:13:42 CET] <faLUCE> do you know what exactly is gop_size ? Has it anything to do with key frames? [01:32:13 CET] <furq> faLUCE: https://en.wikipedia.org/wiki/Group_of_pictures [01:52:48 CET] <thebombzen_> faLUCE: is has everything to do with keyframes [01:53:18 CET] <thebombzen_> a group of pictures is the list of all frames that appear after a keyframe and depend on it [01:53:55 CET] <thebombzen_> so if you have a keyframe every 250 frames, the keyframe and the 249 frames after it is the "group of pictures" [01:54:10 CET] <thebombzen_> in other words gop_size is exactly the distance from one keyframe to the next [12:35:35 CET] <bencc1> I capture the screen with -preset ultrafast to mkv [12:35:58 CET] <bencc1> after that I transcode to mp4 with -preset medium or slow and higher crf [12:36:40 CET] <bencc1> is it reasonable to capture and transcode to mp4 with -preset medium in real time? [12:36:45 CET] <BtbN> you are not going to improve the quality with a reencode [12:37:22 CET] <bencc1> right. I'm not trying to improve the quality but capture fast and later decrease the file size [12:37:40 CET] <bencc1> but I wonder if I can do it in one step in real time [12:37:50 CET] <bencc1> or is transcoding usually slow [12:37:53 CET] <BtbN> yeah, that works. Could also just capture lossless, if you don't care about the size [12:38:10 CET] <bencc1> I do care about the size [12:38:23 CET] <BtbN> The intermediate size? [12:38:43 CET] <BtbN> Also entirely depends on your CPU. A fast CPU can easily do the slow preset in realtime without much effort [12:39:00 CET] <bencc1> possible to transcode in real time with "-preset medium -crf 23" ? [12:39:14 CET] <BtbN> Like I just said, entirely up to your CPU and the load on it. [12:39:29 CET] <BtbN> no other way to find out then to just try it [12:39:44 CET] <bencc1> https://ark.intel.com/products/33929/Intel-Xeon-Processor-L5420-12M-Cache-2… [12:39:52 CET] <bencc1> that's the cpu. a bit old but dedicated [12:40:01 CET] <bencc1> multiple threads can help? [12:40:37 CET] <bencc1> I can also use E3-1230v2 which is newer and faster [12:40:54 CET] <bencc1> 1 thread == 1 core? [12:42:01 CET] <BtbN> not strictly, but in general [12:42:39 CET] <BtbN> Just don't restrict ffmpeg to one thread or something, and you are fine. [12:43:23 CET] <bencc1> ok. I'll try it now without limit [12:43:38 CET] <bencc1> later I'll need to capture several videos at the same time [12:43:51 CET] <bencc1> so I'll try to limit to 1 or 2 threads and see if ffmpeg can keep up [12:44:08 CET] <BtbN> It entirely depends on the system load and CPU speed [12:45:03 CET] <bencc1> ram and disk io are less important than cpu in this case? [13:01:31 CET] <bencc1> BtbN: encoding to mp4 directly during capture seems to work [13:02:06 CET] <BtbN> don't use mp4 for live recordings [13:02:22 CET] <BtbN> use mkv, flv or mpegts or something else that doesn't need a global header [13:03:08 CET] <bencc1> what's the problem with global header? [13:03:17 CET] <bencc1> in case it fail in the middle? [13:03:36 CET] <BtbN> If an mp4 file is not finalized, its entire contents become useless [13:04:52 CET] <bencc1> good point. I'll use mkv and than just convert to mp4 with copy for audio and video and faststart [13:06:41 CET] <bencc1> I'm getting many "Non-monotonous DTS in output stream 0:1; ..." during capture [13:06:44 CET] <bencc1> is this an issue? [13:06:55 CET] <bencc1> does it means that the cpu can't keep up? [14:04:11 CET] <DHE> bencc1: the DTS should be arriving in strictly increasing order. it hasn't been. could be indicative of wraparound or an error in the source [14:04:29 CET] <holdie> Hi guys, when I play a file with ffplay and I try to go fullscreen by pressin f it does not always work, whereas double clicking on the video seems to work okay all the time. As anyone noticed this? (I'm on Linux and just compiled ffmpeg from git) [15:10:06 CET] <bencc1> DHE: the source is x11grab and puseaudio [15:10:10 CET] <bencc1> pulseaudio [16:21:42 CET] <Meins> Hello [16:22:11 CET] <Meins> is someone online how can help me with multicast streaming with ffmpeg? [16:22:22 CET] <JEEB> ffmpeg-all.html [16:24:22 CET] <Meins> Hi Jeeb [16:32:58 CET] <ZeroWalker> hi, i can someone elaborate on the data and linesize on AVFrame, what does it want for an RGBA input? [16:35:30 CET] <JEEB> https://ffmpeg.org/doxygen/trunk/structAVFrame.html [16:35:59 CET] <farfel> hello: I built ffmpeg with openjpeg: how can I verify that it is in fact using the library, rather than built in codec for j2k ? [16:36:10 CET] <JEEB> data are just pointers to uint8_t memory blocks and linesize is the full amount of those until the start of the next line [16:36:27 CET] <JEEB> for example if you align your stuff to a certain alignment the next line will not start right away [16:37:07 CET] <JEEB> and of course depending on situations the linesize can be different between planes [16:46:18 CET] <farfel> aha!!!! figured it out: -c:v libopenjpeg [16:52:50 CET] <JEEB> farfel: yes - that sets the exact decoder for that format [17:00:29 CET] <ZeroWalker> but, hmm, so for RGBA, would data[0] just be the entire pixel array, and linesize[0] be width*4? [17:01:57 CET] <JEEB> linesize depends on the bytewise alignment [17:02:15 CET] <JEEB> I'm pretty sure you want some sort of alignment and I think av_alloc by default gives you some [17:02:28 CET] <JEEB> *av_malloc [17:02:52 CET] <JEEB> although don't quote me on this, I haven't really created AVFrames manually recently :P [17:03:10 CET] <ZeroWalker> is there another way to do it? [17:03:43 CET] <JEEB> I mostly deal with both input and output going through the framework so no real back-to-avframe kind of thing [17:03:59 CET] <JEEB> but yes, you seem to have grasped the general gist [17:04:22 CET] <JEEB> (your example just happened to not take into account any alignment optimizations which would add padding between things [17:07:09 CET] <farfel> Thanks, JEEB [17:07:35 CET] <ZeroWalker> but, wouldn't padding be there by default if it's rgba? as it's 32bit and the width/height is probably always going to be a multiple of 16 i think [17:08:22 CET] <JEEB> anyways, since you're creating the AVFrame you control it [17:08:44 CET] <JEEB> so you can play around and see if anything complains about lack of alignment [17:09:26 CET] <ZeroWalker> but, so, should i just point data[0] to the start of the pixel array, and linesize[0] width*4?;o [17:10:16 CET] <JEEB> I think that's it. you could also try looking at how a created RGBA AVFrame looks when decoded from f.ex. AVCodec [17:11:33 CET] <ZeroWalker> ah, well i will try this to begin with, basically have nothing set up as i have just used pipe before, and now i try to do it in code [17:12:22 CET] <ZeroWalker> http://sprunge.us/MBjT [17:12:28 CET] <ZeroWalker> does this look about right? [17:14:00 CET] <JEEB> wasn't there a function to allocate AVPackets? [17:14:07 CET] <JEEB> just like AVFrames [17:14:12 CET] <JEEB> although E_NO_IDEA [17:14:37 CET] <JEEB> it's been a while since I've used the API and the last time I just blasted avcodec and swscale'd decoded pictures :) [17:15:17 CET] <ZeroWalker> i thought AVPackets where an out in that function;o [17:15:23 CET] <ZeroWalker> meaning i would receive the packet [17:15:35 CET] <JEEB> right [17:16:05 CET] Action: JEEB has done most of his work inside avcodec/avformat :D [17:16:09 CET] <JEEB> not using the APIs [17:16:18 CET] <ZeroWalker> :D [17:44:18 CET] <bencc1> how can I check how many cores ffmpeg use to transcode? [18:09:40 CET] <fritsch> bencc1: top - then press H [19:22:26 CET] <DHE> bencc1: keep in mind each codec - decoder and encoder - may run in multi-threaded mode. so you may end up with a surprisingly high number. [19:32:14 CET] <bencc1> DHE: I see more than 10 processes [19:32:24 CET] <bencc1> but the total cpu % is not too high [20:17:34 CET] <ZeroWalker> i seem to get AVERROR_EXTERNAL when trying to encode2 or send_packet, but i can't find much information go on [20:28:32 CET] <DHE> you mean send_frame ? [20:29:33 CET] <DHE> ultimately it means a (non-specific) error was received from a 3rd party library like x264 and it's being relayed up to you. any logs generated? [20:32:56 CET] <ZeroWalker> yeah think so [20:33:22 CET] <ZeroWalker> no logs sadly, trying to get the thing working, just encoding a frame (RGBA) with libx264 [20:35:23 CET] <ZeroWalker> here is the code i am trying out with: http://sprunge.us/YTcb [21:03:58 CET] <ZeroWalker> no ideas? the code is weird as i try different stuff, but it's the encode2 part that fails (or send_frame if i use that). [21:04:26 CET] <ZeroWalker> i use Zeranoe's libs and dlls [21:18:07 CET] <DHE> well if you're feeding it RGB I think you need to use the libx264rgb codec "variant" [21:20:23 CET] <ZeroWalker> i would like it to be converted to yv12 by ffmpeg [21:20:51 CET] <DHE> I believe you'll have to use a filter or the swscale code directly to do so [21:21:43 CET] <ZeroWalker> hmm, okay let's go with libx264rgb to start with, just wana learn how to even do anything;d [21:22:01 CET] <ZeroWalker> hmm i the rgb version " if (avcodec_open2(context, enc_x264, 0) < 0)" this part fails [22:45:02 CET] <Emil> Hi [22:45:10 CET] <durandal_1707> hi [22:45:16 CET] <Emil> So I compiled ffmpeg with libx264 for raspi 3 [22:45:34 CET] <Emil> And now I'm trying to stram from the raspicam module [22:45:48 CET] <Emil> Does anyone have a readymade config or could help with getting it working? [22:46:03 CET] <Emil> I followed this guide: http://engineer2you.blogspot.fi/2016/10/rasbperry-pi-ffmpeg-install-and-str… [22:47:53 CET] <Emil> Or what's the preferred way to stream a website friendly stream? Personally I would prefer wrapping the native h264 to mp4 but mjpeg would be fine, too [22:50:13 CET] <Emil> durandal_1707: any pointers? [22:50:55 CET] <durandal_1707> just avoid ffserver [22:51:20 CET] <Emil> durandal_1707: what's the preferred way to stream to multiple? [22:51:26 CET] <Emil> If ffserver should be avoided [22:51:51 CET] <RossW> oh? Why so? (I was planning to try using ffserver this week as a one-to-many solution!) [22:52:25 CET] <Emil> I heard (read of on the ffmpeg website) that ffserver support will be dropped [22:52:44 CET] <Emil> but what is the replacement? What should we use to actually stream to multiple? [22:52:59 CET] <durandal_1707> its gonna go away, so for longterm use else smthing [22:53:15 CET] <RossW> well that sucks. What do you suggest? [22:53:24 CET] <RossW> or what do THEY suggest? [22:53:54 CET] <durandal_1707> vlc or smthing else [22:54:03 CET] <Emil> vlc is horrible [22:56:31 CET] <JEEB> so what is the use case with whatever you mean "stream to multiple" [22:56:36 CET] <JEEB> as in, waht does it mean [22:56:55 CET] <JEEB> you encode once and push it to multiple servers? [22:57:02 CET] <Emil> JEEB: http live video [22:57:07 CET] <Emil> website friendly [22:57:15 CET] <Emil> JEEB: anyone can connect and view the stream [22:57:36 CET] <JEEB> that's still generic as <beep>. what's the "multiple" there? [22:57:46 CET] <Emil> I don't quite understand? [22:57:52 CET] <Emil> Multiple as in more than one [22:58:03 CET] <Emil> obviously the resources of my server are limiting actual users [22:58:04 CET] <JEEB> more than one server? client? [22:58:07 CET] <Emil> but that's besides the point [22:58:35 CET] <Emil> JEEB: one raspberry pi that streams video which many clients on lan can connect to [22:58:43 CET] <Emil> and view the stream on their web browsers [22:59:11 CET] <JEEB> look into nginx-rtmp, that takes in RTMP and outputs HLS and DASH [22:59:44 CET] <Emil> That seems silly [22:59:53 CET] <JEEB> why? [23:00:00 CET] <JEEB> you transcode once, and then the server handles packaging [23:00:21 CET] <JEEB> RTMP as ingest can sound bad, but it seems to work. other servers take in fragmented ISOBMFF or whatever [23:01:11 CET] <JEEB> that way you can also completely separate transcoding and serving, so that load from the first thing doesn't affect the latter [23:20:44 CET] <jcay> hello... can concat function work with resize (-s) at the same time? [23:21:16 CET] <bencc1> there is also https://github.com/kaltura/nginx-vod-module [23:21:55 CET] <bencc1> I think that Facebook live and Youtube live receive RTMP as well [23:22:10 CET] <JEEB> as long as you're OK with AGPLv3 the kaltura thing is OK as well [23:22:53 CET] <BtbN> everything uses rtmp for streaming [23:23:36 CET] <JEEB> yes, it's a common thing for ingest these days [23:26:50 CET] <bencc1> JEEB: is there something wrong with AGPLv3 as long as you treat the packing server as black box? [23:27:25 CET] <bencc1> nginx-rtmp has the same features as kaltura's module? [23:28:10 CET] <thebombzen> jcay: depends on how you're concatenating [23:28:17 CET] <JEEB> the thing of having to give the source code of at least your whole nginx build can be an effort [23:28:41 CET] <JEEB> but if you cut it at that nginx then I guess it's not too bad as long as anything else doesn't get touched [23:28:49 CET] <thebombzen> jcay: if you're using the concat filter, then yes. but remember that you can only resize if you transcode [23:30:38 CET] <thebombzen> out of curiosity, is there any practical advantage to using the -s and -pix_fmt options, rather than just appending -vf scale and -vf format to the filterchain? [23:30:52 CET] <JEEB> no [23:31:19 CET] <thebombzen> it sounds like the only reason you'd want to is for several video streams [23:31:23 CET] <JEEB> I think there's just enough of those old guides that use the "short-hands" [23:31:38 CET] <JEEB> well for several video streams you can always do -vf:v:0 [23:31:40 CET] <thebombzen> but -vf:v should work for several streams right [23:31:44 CET] <JEEB> yes [23:32:12 CET] <thebombzen> you could view -s as syntactic sugar perhaps if you don't already have a filterchain [23:32:16 CET] <thebombzen> cause it's short [23:47:10 CET] <jcay> thebombzen: was the question to me? [23:47:25 CET] <thebombzen> no you asked the question to us [23:47:30 CET] <thebombzen> and I answered it [23:47:58 CET] <jcay> you asked if there is advantage is using -s [23:49:48 CET] <thebombzen> no I asked the question to everyone here, and it was answered [23:50:12 CET] <thebombzen> you mentioned -s which prompted me to think about the option, and therefore ask the question. but it wasn't related to your question [23:51:20 CET] <jcay> oh I see, sorry :) [23:53:35 CET] <jcay> it seemed to me to be a better option for tonight to downscale every movie and then concatenate, too tired to learn more [00:00:00 CET] --- Mon Mar 6 2017

1 0

ffmpeg-devel.log.20170304
by burek 05 Mar '17

05 Mar '17

[02:29:03 CET] <cone-470> ffmpeg 03Steven Liu 07master:4507f29e4a6a: avformat/hlsenc: move the segment files handler close to before temp flags process [03:06:52 CET] <cone-470> ffmpeg 03Michael Niedermayer 07master:2ce4f2843162: avcodec/vp56: Require a correctly decoded frame before using vp56_conceal_mb() [03:06:53 CET] <cone-470> ffmpeg 03Michael Niedermayer 07master:eb41956636fc: avcodec/mpeg4videodec: Improve the overflow checks in mpeg4_decode_sprite_trajectory() [09:17:17 CET] <paras2052> Hello Everyone ! I am paras chadha, 3rd year Undergraduate in Btech CSE. I am interested in the FITS image decoder and encoder project for GSOC 2017. [09:18:42 CET] <paras2052> I am new to FFmpeg and i want to work on the qualification task but i need some advice as where to begin [09:48:13 CET] <durandal_1707> paras2052: write decoder, there is also already xpm patch on mailing list by me which needs only some changes [09:52:25 CET] <paras2052> durandal_1707: Okay, I am working on it. [10:10:43 CET] <durandal_1707> paras2052: have you found patch? [10:12:50 CET] <paras2052> durandal_1707: yes, i have found it in the archives [10:38:19 CET] <durandal_1707> [13:23:58 CET] <michaelni> atana, if you need help/more details on how to use ff_generate_window_func() say so and ill explain how its exactly used [16:28:01 CET] <dev_123> @omerjerk I'm interested in the project "MPEG-4 ALS codec improvements". Kindly guide where to begin from. [16:45:42 CET] <dev_123> @BBB I'm interested in the project "MPEG-4 ALS codec improvements". Can you guide me about where to start ? [16:46:05 CET] <BBB> Im not in charge of that project, sorrt [17:11:00 CET] <dev_123> @BBB Where can I contact the mentor of this project, which I can see from the project ideas list is Omerjerk. But he is not present here. [17:28:05 CET] <nevcairiel> the primary mentor has an email listed, try that [17:28:16 CET] <adeel_> durandal_1707: did you take a look at the diff file I shared yesturday? [17:30:29 CET] <durandal_1707> adeel_: nope [17:30:46 CET] <durandal_1707> adeel_: did you got decoding working? [17:31:55 CET] <adeel_> durandal_1707: the problem was with the XPM file. You told me to add code for removing C comments. But, then there was another issue and you mentioned somthing about probing. [17:32:22 CET] <adeel_> durandal_1707: here the latest diff: https://gist.github.com/adl1995/5b3f681ba2c710915cc6cf567d3cdb83 [17:34:05 CET] <durandal_1707> adeel_: still lot of stuff missing [17:34:20 CET] <adeel_> durandal_1707: :/ like what? [17:34:41 CET] <durandal_1707> adeel_: have you followed xbmdec logic regarding ff get buffer? [17:35:05 CET] <durandal_1707> you just commented bunch of code [17:35:50 CET] <durandal_1707> follow xbmdec logic to get decoded output [17:40:22 CET] <adeel_> durandal_1707: I think I already did. Let me check again [17:40:46 CET] <durandal_1707> adeel_: you put it commented in wrong place [17:41:15 CET] <adeel_> durandal_1707: okay, checking [17:41:25 CET] <durandal_1707> do you have any idea how simple intra only decoders work? [17:42:28 CET] <durandal_1707> you just call ff get buffer before you need to play with output pointers [17:57:18 CET] <adeel_> durandal_1707: Is there a method names "ff_get_vbuffer" or did I just make a typo? [17:57:23 CET] <adeel_> named* [17:57:35 CET] <durandal_1707> yes typo [17:58:20 CET] <adeel_> durandal_1707: alright, going through the compilation process again [18:06:09 CET] <adeel_> durandal_1707: after issuing these commands './configure', 'make install', and 'ffplay /test.xpm'. I'm getting this error "/test.xpm: Invalid data found when processing input" [18:06:30 CET] <adeel_> durandal_1707: probably something wrong in xpmdec.c [18:07:21 CET] <durandal_1707> adeel_: make sure decode frame is being called [18:07:48 CET] <cone-806> ffmpeg 03Michael Niedermayer 07master:d23727e0420b: avcodec/adxdec: Fix runtime error: left shift of negative value -1 [18:07:48 CET] <cone-806> ffmpeg 03Michael Niedermayer 07master:ab998f4c7faf: avcodec/h264_mvpred: Fix multiple runtime error: left shift of negative value [18:07:48 CET] <cone-806> ffmpeg 03Michael Niedermayer 07master:d757ddbaab8f: avcodec/mpeg12dec: Fix runtime error: left shift of negative value -13 [18:07:53 CET] <adeel_> durandal_1707: okay, will output something [18:08:30 CET] <adeel_> No, it isn't being called. I added 'printf("Testing XPM decoder");' at the beginning [18:13:19 CET] <durandal_1707> adeel_: try different xpm file [18:19:07 CET] <adeel_> durandal_1707: using this:https://github.com/ifwe/wx/blob/8ef3ca2eff1acc6de1c40d1ccc2112c1f5cddf… still getting the same " Invalid data found when processing input" error though [18:25:02 CET] <durandal_1707> adeel_: can you push you branch to your repo on github? [18:25:53 CET] <adeel_> yes [18:30:59 CET] <adeel_> durandal_1707: please take a look: https://github.com/adl1995/FFmpeg/tree/new_branch [18:31:55 CET] <adeel_> durandal_1707: only last two commits are relevant [18:34:04 CET] <durandal_1707> adeel_: is ffplay build shared? [18:59:43 CET] <atana> michaelni, updated repo. How do I initialize window_func_lut ? [19:02:18 CET] <adeeln2> durandal_1707: sorry for the late reply. Not sure what you mean why ffplay build. Do you mean the ffplay.c file? [19:03:25 CET] <durandal_1707> adeeln2: i mean if its shared you need to install itt [19:04:25 CET] <adeeln2> durandal_1707: oh yes it is installed. I'm currently using this command: 'ffplay ~/test1.xpm' [19:05:29 CET] <durandal_1707> adeeln2: does ffmpeg -decoders list xpm? [19:07:12 CET] <adeeln2> nope [19:08:57 CET] <michaelni> atana, the 2nd parameter to the function is the number of samples in the window, so the first parameter which is the window needs to be allocated to that size times sizeof(float) [19:10:17 CET] <atana> ok [19:11:06 CET] <durandal_1707> adeeln2: so you need to run make install [19:17:59 CET] <adeeln2> durandal_1707: I just did. But, it's still not showing. Maybe it's somehow pointing to the old build? [19:23:13 CET] <durandal_1707> adeeln2: whats not showing? [19:24:00 CET] <adeeln2> durandal_1707: On issuing 'ffmpeg -decoders', I don't see XPM in the list. [19:24:34 CET] <atana> michaelni, do you mean window_func_lut = av_realloc_f(window_func_lut, m, m*sizeof(float)) ? [19:25:10 CET] <durandal_1707> adeeln2: then find where is ffmpeg being installed [19:25:28 CET] <durandal_1707> if its installed at all [19:28:25 CET] <durandal_1707> adeeln2: does ffplay now works? [19:29:38 CET] <adeeln2> durandal_1707: accessing from same directory using './' after issuing './ffplay ~/test1.xpm' I now get " 28586 segmentation fault (core dumped) " [19:30:08 CET] <durandal_1707> adeeln2: thats because your code is wrong [19:30:21 CET] <michaelni> atana, no that would multiply by m twice but av_malloc_array() is better [19:30:32 CET] <durandal_1707> you need to call get buffer before using pointers [19:30:38 CET] <adeeln2> durandal_1707: should I try to replicated xbmdec.c? [19:30:48 CET] <durandal_1707> adeeln2: no [19:31:05 CET] <durandal_1707> adeeln2: just learn to work with pointers [19:31:30 CET] <durandal_1707> adeeln2: move ff get buffer above its too low [19:31:39 CET] <michaelni> atana, and the window should be stored in the context not calculated repeatly [19:31:40 CET] <adeeln2> durandal_1707: okay [19:31:59 CET] <durandal_1707> seriously im helping you too much [19:32:04 CET] <atana> ok [19:32:41 CET] <michaelni> the window never changes so theres no need to calculate it more than once [19:38:22 CET] <durandal_1707> adeeln2: you dont have xpm listed in -decoders because libavcodec/codec_desc.c is missing xpm [19:38:49 CET] <durandal_1707> adeeln2: also please remove uneeded files from your code [19:39:12 CET] <durandal_1707> like txt patch and similar you put there [19:40:07 CET] <adeeln2> okay [19:44:05 CET] <nightlingo> hi [19:44:29 CET] <durandal_1707> hi [19:47:32 CET] <adeeln2> durandal_1707: please review: https://github.com/adl1995/FFmpeg/commit/de437d43cf634b077c797264472d003aae… [19:48:06 CET] <atana> michaelni, repo updated [19:48:14 CET] <adeeln2> now getting this: Testing XPM decoder[xpm @ 0x7f4798007480] [IMGUTILS @ 0x7f479e71b6f0] Picture size 0x0 is invalid [xpm @ 0x7f4798007480] video_get_buffer: image parameters invalid [xpm @ 0x7f4798007480] get_buffer() failed [image2 @ 0x7f47980008c0] decoding for stream 0 failed [image2 @ 0x7f47980008c0] Could not find codec parameters for stream 0 (Video: xpm, none): unspecified size Consider increasing the value for the 'ana [19:48:29 CET] <adeeln2> decoder function is now being called [19:49:30 CET] <durandal_1707> adeeln2: good, guess it is missing parsing and ignoring " in comments [19:50:25 CET] <nightlingo> I want split a small portion of a .mp4 video using ffmpeg, without re-encoding it and get the output sent to stdout. I reallized that ffmpeg doesn't support outputting an .mp4 video to stdout because the MP4 muxer needs the ability to seek back in a stream. Then I tried outputting a fragmented mp4 video, which worked for stdout, but it turns out it is not supported by several players like Windows 7 Media Player. Any other suggesti [19:50:25 CET] <nightlingo> please? [19:51:18 CET] <nightlingo> *to [20:00:48 CET] <adeeln2> durandal_1707: alright. Would I have to replicate with from xbmdec or write my own? [20:02:25 CET] <durandal_1707> adeeln2: looks like it works fine without it [20:03:41 CET] <durandal_1707> adeeln2: the xpm you linked works fine here [20:04:25 CET] <durandal_1707> nightlingo: use mkv [20:05:05 CET] <adeeln2> durandal_1707: oh, cool. what's next? [20:07:48 CET] <durandal_1707> adeeln2: fix it so it works for you to and add >256 color support [20:08:16 CET] <adeeln2> durandal_1707: okay, will get on it tomorrow. thanks! [20:08:38 CET] <michaelni> atana, ok, next you need to apply the window on the data before the FFT [20:10:20 CET] <michaelni> atana, that is the samples are multiplied by the values from the window befor the fft [20:15:35 CET] <nightlingo> durandal_1707: or, avi, right? [20:16:11 CET] <durandal_1707> maybe [20:18:59 CET] <nightlingo> durandal_1707: thank you, I will try it [20:37:15 CET] <nightlingo> durandal_1707: unfortunately neither .mkv nor .avi files produced using stdout are playable by Windows Media Player 7 [20:38:48 CET] <nightlingo> Im wondering, maybe there is a way to simply copy the portion of the mp4 Im interested in and then re-calculate the MOOV atom and attach it to the end of the new file? [20:47:50 CET] <BtbN> use mpeg-ts if you want to freely cut and copy without the need to seek [20:50:00 CET] <nightlingo> BtbN: this is a .mts file suffix? [20:53:13 CET] <nightlingo> BtbN: ffmpeg says: Requested output format 'mts' is not a suitable output format [20:53:14 CET] <nightlingo> pipe:1: Invalid argument [20:53:30 CET] <kierank> ts [20:53:32 CET] <kierank> or m2ts [20:58:41 CET] <nightlingo> I tried both , it says that they are not a suitable format [20:58:43 CET] <nightlingo> I run it as: [20:58:53 CET] <nightlingo> ffmpeg -ss 00:00:10 -t 00:00:20 -i inputfile.mp4 -f m2ts pipe:1 > out.mp4 [20:59:56 CET] <unholy_me> hello devs! [20:59:58 CET] <kierank> mpegts [21:00:26 CET] <unholy_me> something I want to clear about decoders [21:01:10 CET] <unholy_me> Is a square decoder a type of Regular Polygon decoders? [21:02:07 CET] <durandal_1707> unholy_me: yes [21:02:35 CET] <durandal_1707> its mentioned in wikipedia entry [21:02:53 CET] <unholy_me> Ya I just saw that [21:03:24 CET] <unholy_me> However the formula given is for 3 channels only [21:03:53 CET] <unholy_me> How do I calculate for 4 channels (ambisonic sound) [21:03:58 CET] <durandal_1707> unholy_me: because z is not used [21:04:21 CET] <durandal_1707> unholy_me: formula is in wikipedia [21:04:33 CET] <durandal_1707> you just need to copy it [21:05:44 CET] <unholy_me> okay.... [21:05:52 CET] <BtbN> building with -j16 is fun [21:06:01 CET] <unholy_me> Why is z not used.. if I may? [21:06:41 CET] <nightlingo> kierank: thanks, its working now! [21:06:42 CET] <durandal_1707> unholy_me: because all speakers are on same plane [21:07:22 CET] <unholy_me> Okay! z is the height constraint...ok [21:07:25 CET] <nightlingo> Do you think its safe to save the mpegts file with a .mp4 suffix? it seems to be playing on VLC and Windows Media Player, but maybe there would be any other implications Im not aware of? [21:08:34 CET] <unholy_me> In Ambisonic Sound: " It covers sound sources above and below the listener " [21:08:53 CET] <unholy_me> Why is it given like this [21:08:54 CET] <unholy_me> ? [21:10:14 CET] <unholy_me> Sorry, I found the right material, ignore the questions [21:28:42 CET] <paras2052> durandal_1707: hi, thank you for reviewing the code. Is there any documentation of the new API that shows the changes made to the old API. Currently i am looking at the definitions of structs to see which functions and variables have been removed. [21:30:28 CET] <durandal_1707> there was no docs just flag that its deprecated [21:30:44 CET] <durandal_1707> just remove commented code out [21:30:59 CET] <durandal_1707> and make sure it decodes files [21:31:12 CET] <paras2052> okay, yes doing that [21:41:34 CET] <wm4> read doc/APIchanges to see what changed [21:42:46 CET] <paras2052> wm4: okay, thanks. let me see [22:33:34 CET] <madguy02_> hii,i wanted to know how to start contributing towards ffmpeg and learn more about developing on it [00:00:00 CET] --- Sun Mar 5 2017

1 0

ffmpeg.log.20170304
by burek 05 Mar '17

05 Mar '17

[04:00:00 CET] <slalom> anybody know what the difference is between the 'baseline' profile and 'constrained baseline'? I'm trying to match some output example data we got as well as possible.. i'm building with -profile:v baseline but instead of the video stream coming out as Video: h264 (Baseline) it outputs as Video: h264 (Constrained Baseline) [04:03:52 CET] <relaxed> slalom: https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles [04:04:38 CET] <furq> slalom: usually when someone says baseline they mean constrained baseline [04:04:53 CET] <furq> confusingly there is a separate baseline profile but i don't think anyone really uses it [04:15:58 CET] <slalom> furq: i see that it's a separate one in that link, but is there any way for ffmpeg to build so that the result actually outputs as h264 (Baseline)? i mean, i chose baseline [04:16:49 CET] <slalom> we deploy a 3g-bandwidth version of the media for android, and the example output for that that im trying to match is just Baseline [04:17:27 CET] <furq> i don't think x264 can do that [04:17:41 CET] <furq> x264 --profile baseline is constrained baseline [04:18:02 CET] <furq> you could maybe try a different h264 encoder but i wouldn't know where to start really [04:18:38 CET] <slalom> damn [04:18:52 CET] <slalom> ive spent weeks on this and may have to bail on it [04:19:28 CET] <slalom> i'm basically replacing a pipeline of a producer here where he had to run 15 different encoding presets in adobe media encoder, then copy stuff to a mac and package HLS [04:19:31 CET] <slalom> i said i could do it all in ffmpeg [04:19:52 CET] <slalom> everything is working other than the android presets, which are profile baseline level 3.0 [04:20:30 CET] <slalom> still not entirely sure why they're not working yet though, im just investigating differences in the formats at the moment [04:22:24 CET] <furq> only really old/cheap android devices need baseline [04:22:34 CET] <slalom> yeah... [04:22:43 CET] <slalom> i guess that's the failsafe target i dunno [04:23:29 CET] <furq> also bear in mind that -level in ffmpeg usually doesn't do much [04:23:44 CET] <slalom> i just used it because i'm copying the adobe media encoder preset values [04:23:47 CET] <furq> e.g. you can't encode a 720p video with -level 3.0 and get a level 3.0 video [04:25:58 CET] <furq> annoyingly it will still write the provided level into the sps [04:26:09 CET] <slalom> weird [04:26:11 CET] <furq> i guess you could encode it without -level and see what level ffprobe says it is [04:26:31 CET] <slalom> i need to find out more about how it 'didnt work', he just said it said 'network error' but i dont know if that's a browser error or an error inside our app trying to stream the file [04:54:04 CET] <c3r1c3-Win> I'm getting the error Error code -22. Error in av_frame_get_buffer in the ffmpeg_acompressor_filter_audio function(failure to allocate frame). [04:54:28 CET] <c3r1c3-Win> But I can't seem to find any documentation on errors codes. [06:22:43 CET] <gp5st> `-profile:v baseline -level 3.0 -s 720x486 -b:v 512k -minrate:v 256k -maxrate:v 1.25m -preset veryslow -start_number 0 -hls_time 4 -hls_segment_filename 'if1zwfoxJSs/stream%05d.ts' -hls_list_size 0 -f hls if1zwfoxJSs/stream.m3u8` i'm confused bow -b:v -minrate:v and -maxrate:v interact here. is -b:v the target average? or just what it tries to hit each time, but based on some criteria can change? [06:30:20 CET] <furq> minrate doesn't actually do anything with x264 afaik [06:30:32 CET] <furq> although even if it did, it's not actually useful [06:30:55 CET] <furq> also i'm not sure what maxrate does without bufsize set [06:31:31 CET] <gp5st> yet more evidence that I don't know anything [06:32:03 CET] <furq> in short, the average bitrate can't exceed maxrate in every bufsize bytes [06:32:12 CET] <furq> b:v is just the target bitrate [06:36:01 CET] <gp5st> are there any other stupid things I'm doing there? [06:38:25 CET] <furq> there's not really any point having maxrate so much higher than average bitrate [06:39:23 CET] <furq> if you're prepared to have the bitrate spike that high then you might as well just have the average bitrate be close to that [06:40:56 CET] <gp5st> hmm [06:42:01 CET] <gp5st> is it worth even specifying a max then? and just let ffmpeg do it's thing? [06:42:18 CET] <furq> you probably want to set a maxrate for live streaming [06:43:25 CET] <furq> if anything you'd want to drop the average bitrate and use crf mode with maxrate/bufsize [06:44:34 CET] <gp5st> thanks :) [06:47:19 CET] <gp5st> something else I noticed, I have -hls_time 4 but a lot of my segments are 8s long [06:52:57 CET] <furq> you probably want to set -g and -x264-params keyint-min [06:54:02 CET] <furq> just -g is probably ok [06:59:35 CET] <gp5st> thanks. I saw that but thought -hsl_time would force that/figure it out [07:08:47 CET] <mritunjay> help,me to get started. i do code in c,tell me from where to move on. [07:14:47 CET] <c3r1c3-Win> mritunjay: What are you trying to do? [07:23:36 CET] <mritunjay> sir,i look for "FITS image decoder and encoder,VMAF video filter". [07:28:53 CET] <c3r1c3-Win> mritunjay: The Google Summer of Code? https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2017 [07:35:06 CET] <mritunjay> c3r1c3-Win: i have to known how ,i can start contributing. [07:35:50 CET] <c3r1c3-Win> mritunjay: The info is on the page that I linked. [07:35:59 CET] <mritunjay> ok [07:43:54 CET] <mritunjay> how can i join the mailing lists [07:44:42 CET] <c3r1c3-Win> mritunjay: The info is on the page that I linked... or rather the page has a link on it to more info. [08:48:17 CET] <Commander_Cody> An ffmpeg command crashed. [08:48:23 CET] <Commander_Cody> How could I resume it? [08:50:31 CET] <Commander_Cody> ffmpeg -i input -ss 1:00:00 -to 1:30:00 -vcodec foo -acodec bar output [08:50:43 CET] <Commander_Cody> How could I resume that if my computer crashed while running it? [09:03:04 CET] <tdr> next time run it through a job scheduler with checkpoints [09:05:15 CET] <Commander_Cody> tdr? [12:04:13 CET] <faLUCE> Hello. I have file1.ts and file2.ts (video only, h264, mpegts). both can be viewed with ffplay, vlc and mplayer, but file1 has some problems (timestamps?) with vlc and mplayer . Here's the output of ffprobe for both: http://paste.ubuntu.com/24108391/ . Where can be the error on file1? I see that ffprobe shows framerate for file2 and no framerate for file1, but I did not set any framerate while creating both of them.... [12:04:14 CET] <faLUCE> . [12:07:31 CET] <faLUCE> In addition, I see that ffprobe for file1 shows "1/2000000", which I don't understand [13:09:38 CET] <oal> I'm trying to record a screencast with ffmpeg in Linux (Gnome 3) and I get flickering where sometimes the window behind the active window shines trhough [13:11:38 CET] <oal> https://dl.dropboxusercontent.com/u/262587/output.avi like in the beginning of this short recording [13:11:54 CET] <oal> Any ideas how to avoid that? [14:44:45 CET] <faLUCE> Hello. When probing somefile.ts I obtain this info: Stream #0:0, 61, 1/1200000: Video: h264 (Constrained Baseline), 1 reference frame, yuv420p(left), 640x480, 1/2000000, 25 fps, 1000k tbr, 1200k tbn, 2000k tbc . What is "1/2000000"? Is it the timebase of the encoder? [16:32:20 CET] <Threads> any reason ffmpeg is bad at concating mkv but its fine with mp4 ? [16:32:41 CET] <Threads> keep getting something about autoh264blahblah with mkv but its fine with mp4 [16:36:13 CET] <BtbN> probably because the contents of your mp4 files match, but the mkvs don't. [17:36:05 CET] <thebombzen_> hey, I upgraded cuda (to 8.0 I think) and nvenc doesn't work anymore. is this known or is there something wrong with my setup? [17:36:40 CET] <durandal_1707> your setup [17:36:58 CET] <durandal_1707> dont touch something that works [17:38:48 CET] <thebombzen_> well I'm sorry I'm on Arch and upgraded my system? [17:39:19 CET] <thebombzen_> either way, what's interesting is that if I run: ffmpeg -f lavfi -i testsrc -c h264_nvenc -gpu list -f null - [17:39:25 CET] <klaxa> i'm surprised my computer didn't catch fire when i updated my arch given how much shit updates broke [17:39:45 CET] <thebombzen_> if I run that command, it'll hang for a bit, but then it'll dow hat's expected [17:39:47 CET] <thebombzen_> list my two GPUs [17:40:00 CET] <thebombzen_> and then exit immediately after listing both gpus [17:40:40 CET] <thebombzen_> however, if I actually attempt to do a test encode (e.g. with -gpu any instead of -gpu list) then it'll hang and then fail [17:40:47 CET] <thebombzen_> claiming that no nvenc-capable devices found. [17:41:03 CET] <thebombzen_> lemme pastebin my uncut output one second [17:42:58 CET] <thebombzen_> oh interesting, this is different behavior than yesterday [17:44:19 CET] <thebombzen_> can anyone give me some insight on this error? "[h264_nvenc @ 0x55c547cb7860] Failed creating CUDA context for NVENC: 0x3e7" [17:44:53 CET] <thebombzen_> now according to dur (the maintainer) it's not an ffmpeg issue and I believe that but does anyone have any insight into the problem? [17:46:53 CET] <jkqxz> <http://docs.nvidia.com/cuda/cuda-driver-api/group__CUDA__TYPES.html#group__…> says that return code is "unknown internal error". [17:47:03 CET] <jkqxz> So you probably need the source code for the nvidia driver to determine anything at all. [17:48:48 CET] <jkqxz> If you don't have the source code then sucks to be you. Maybe reinstall it, or try a different version? [18:11:21 CET] <BtbN> thebombzen, "updated CUDA"? So, you updated your nvidia driver? [18:11:28 CET] <BtbN> Because that's the only external thing ffmpeg uses. [18:30:39 CET] <thebombzen_> upon some googling, it looks like there is a bug, where if you suspend your system after an nvenc session has happened, and then reload the system, you won't be able to try again [18:30:51 CET] <thebombzen_> and reloading the nvidia_uvm module should fix this [18:31:21 CET] <thebombzen_> unfortunately for me it didn't fix it, AND my system didn't get suspended, so I don't know what to try here [18:32:37 CET] <BtbN> reboot [18:32:48 CET] <BtbN> If it still doesn't work, something's wrong with your driver. [18:34:49 CET] <thebombzen_> well I didn't upgrade the driver, just cuda. but yea reloading the driver is a thing. I just didn't want to "reboot fixes it" cause it feels like I'm on NT or something. but when we're talking drivers and kmods then it might actually be the right thing to do [18:35:12 CET] <BtbN> There is nothing to upgrade there. [18:35:37 CET] <BtbN> ffmpeg purely depends on the nvidia driver, except for libnpp, which is non-free though [18:37:17 CET] <thebombzen_> well, it may be a surprise, but cuda isn't teh same thing as the nvidia driver [18:37:33 CET] <thebombzen_> nvidia's driver is with the Arch package "nvidia" and cuda is with the package "cuda" [18:38:22 CET] <thebombzen_> nvidia is the thing that installs the kernel module that allows your graphics card to render your display (i.e. The Driver) and the Cuda package provides the headers and libraries to just the Common Unified Device Architecture [18:38:31 CET] <thebombzen_> so no, cuda != drivers [18:39:14 CET] <JEEB> cuda being the cuda sdk then, because I'm pretty sure the runtime comes with the drivers (although I'm not 100% sure since I haven't run CUDA-using apps lately :P) [18:39:18 CET] <BtbN> all libraries ffmpeg uses for nvenc and cuvid come from the nvidia driver [18:39:37 CET] <BtbN> It has no dependencies on CUDA specific libraries(except for libnpp), and it has no dependencies on any external headers. [18:40:17 CET] <thebombzen_> this is not correct [18:40:18 CET] <thebombzen_> http://0x0.st/JR2.txt [18:40:30 CET] <BtbN> those come from the nvidia-driver. [18:40:40 CET] <thebombzen_> no they don't [18:40:44 CET] <BtbN> yes they do [18:40:48 CET] <thebombzen_> the nvidia driver doesn't have libcuda, I'm trying to tell you [18:40:54 CET] <BtbN> It does [18:40:59 CET] <thebombzen_> literally click the link [18:41:12 CET] <BtbN> I did, and those libraries are part of the nvidia driver. [18:41:27 CET] <JEEB> I've not chekced the actual nvidia archives but it's quite possible that arch has just separated things around in addition to the SDK :P [18:41:44 CET] <thebombzen_> well then if you clicked the link [18:41:44 CET] <JEEB> the SDK *is* definitely separate from the driver [18:41:55 CET] <thebombzen_> and they're part of the Nvidia driver, then why are they not in the "nvidia" package [18:42:01 CET] <thebombzen_> which doesn't depend on cuda [18:42:03 CET] <JEEB> because arch? [18:42:16 CET] <thebombzen_> yea but it's possible to install the nvidia driver without installing libcuda [18:42:18 CET] <JEEB> although like I just said I haven't looked at the contents of the latest nvidia binaries [18:42:23 CET] <thebombzen_> ergo they're NOT part of the nvidia driver [18:42:24 CET] <BtbN> Only if you use some botched package [18:42:34 CET] <BtbN> The official installer and any sane package of it brings it [18:42:39 CET] <thebombzen_> BtbN: do you just not know when to quit [18:42:59 CET] <JEEB> umm, what BtbN seems to be saying is that arch took the thing that nvidia distributes [18:43:02 CET] <JEEB> and separated it [18:43:05 CET] <JEEB> into two packages [18:43:16 CET] <thebombzen_> yea, but the kernel module doesn't actually pull in cuda [18:43:18 CET] <BtbN> I'm looking at the nvidia driver archive right now, and it's all there. [18:43:28 CET] <thebombzen_> you can install the driver without installing cuda [18:43:30 CET] <JEEB> thebombzen_: that's something arch decided [18:43:40 CET] <BtbN> There is no "Pull in CUDA". The CUDA SDK is just for development against it. Everything else for the runtime comes with the driver. [18:43:53 CET] <BtbN> And ffmpeg does not need the SDK for building. [18:43:56 CET] <JEEB> I'd trust on BtbN what nvidia distributes within the driver package [18:44:13 CET] <thebombzen_> BtbN: it's not accurate that the runtime comes with the driver. [18:44:15 CET] <JEEB> arch can optimize and separate and cut things around how it wants, I guess [18:44:21 CET] <BtbN> Yes it is... [18:44:27 CET] <thebombzen_> libcuda.so comes with cuda, not with nvidia [18:44:27 CET] <JEEB> thebombzen_: for your distribution, because they decided to cut it around [18:44:33 CET] <thebombzen_> YES FOR MY DISTRIBUTION. THIS MATTERS. [18:44:44 CET] <thebombzen_> because my statement was "I updated cuda but didn't update my driver" [18:44:58 CET] <JEEB> ok, as long as you understand. but for anyone else the official driver package is what consists as a driver [18:44:58 CET] <thebombzen_> BtbN is trying to claim that this is impossible because they're distributed together [18:45:09 CET] <BtbN> Well, if you mix different versions of files that are supposed to be installed together with one driver installer, stuff exploding is about to be expected. [18:45:12 CET] <thebombzen_> and I'm saying, no it's definitely possible, because I literally just did it. [18:45:37 CET] <thebombzen_> so don't try to tell me that I can't upgrade cuda without upgrading the driver, because I just did, and I can send you the file listing of the separate packages if you don't believe me. [18:45:49 CET] <BtbN> Nvidia gives absolutely no backward or forward compatiblity between their driver releases and libraries from them [18:46:02 CET] <BtbN> Seems to be working great what you just did [18:46:23 CET] <thebombzen_> http://sprunge.us/FOZX [18:46:24 CET] <BtbN> And I can send you the file listing of all files coming from x11-drivers/nvidia-drivers, so? [18:46:47 CET] <thebombzen_> on your distribution? yea but that doesn't matter [18:46:47 CET] <BtbN> Doesn't change anything. All that matters is how the nvidia driver is intended to be used. If Arch decided to split it, you have to live with the consequences of that. [18:47:05 CET] <BtbN> So your distribution matters, but none else. Great. [18:47:05 CET] <thebombzen_> I'm only trying to explain to you is that I did actually udpate cuda without updating the driver. [18:47:21 CET] <thebombzen_> well you're the one who said, "You can't update cuda without updating the driver." [18:47:22 CET] <BtbN> And I'm trying to explain you that that's not intended and you already found out what it causes. [18:47:24 CET] <thebombzen_> Well, yes, I can. [18:50:11 CET] <thebombzen> well either way, I'm going to reboot. I don't like that nvidia makes you do that all the time but they're probably not used to catering to users who usually don't have to do that [18:51:15 CET] <BtbN> unloading all (nvidia) kernel modules and completely restarting X should have the same effect [18:51:40 CET] <BtbN> And if you really have mixed versions of the cuda libraies and the rest of the nvidia driver: fix that [18:55:15 CET] <thebombzen_> either way, just reloading the kernel module by rebooting fixed it. I just find it strange that it would be necessary [18:55:31 CET] <thebombzen_> given that I tried unloading and reloading the module and that didn't do it. (rmmod && modprobe) [19:00:10 CET] <BtbN> all modules? [19:00:12 CET] <BtbN> Or just uvm? [19:00:21 CET] <BtbN> Nvidia has quite a few by now [19:00:25 CET] <BtbN> uvm, kvm, nvidia, ... [19:00:31 CET] <BtbN> *kms [19:12:45 CET] <faLUCE> Hello. I have file1.ts and file2.ts (video only, h264, mpegts). both can be viewed with ffplay and vlc, but file1 is not seekable with vlc. Is there a way to detect if it contains errors, with ffprobe? Otherwise, what could I check? [19:14:34 CET] <faLUCE> I compared them with wireshark, and the only difference seems "random access indicator" flag, which is set to 0 in file1, and to 1 in file2 [19:36:35 CET] <thebombzen_> the module in question was uvm [19:36:40 CET] <thebombzen_> that's teh one that handles the nvenc [19:36:54 CET] <thebombzen_> the module "nvidia" just drives the display [19:37:58 CET] <thebombzen_> I have loaded nvidia, nvidia_drm, nvidia_uvm, and nvidia_modeset [19:44:03 CET] <nightlingo> hello! [19:44:14 CET] <thebombzen_> Hello [19:54:27 CET] <nightlingo> I want to split a small portion of a .mp4 video using ffmpeg, without re-encoding it and get the output sent to stdout. I reallized that ffmpeg doesn't support outputting an .mp4 video to stdout because the MP4 muxer needs the ability to seek back in a stream. Then I tried outputting a fragmented mp4 video, which worked for stdout, but it turns out it is not supported by several players like Windows 7 Media Player. Any other suggestion [19:54:28 CET] <nightlingo> please? [19:56:39 CET] <DHE> faLUCE: RAI should be set on any video keyframe [19:56:49 CET] <DHE> or at least the first segment of i [19:56:50 CET] <DHE> it [20:38:37 CET] <BtbN> thebombzen_, you still have to reload all of them. They all interact [20:38:51 CET] <BtbN> Might even get a version mismatch message in dmesg if you don't. [20:48:49 CET] <thebombzen_> well rebooting fixed it [20:49:05 CET] <thebombzen_> but the solution I found specifically said "reload nvidia_uvm" [20:49:38 CET] <thebombzen_> doing "rmmod nvidia" would probably have messed it up a bit more because I'd lose my xserver, which would be sort of a pain because my display manager is on [20:50:37 CET] <thebombzen_> if I shut off lightdm then upon restarting I'd have a graphical prompt to log in to a user account, which is not possible for me to do easily remotely [20:50:49 CET] <thebombzen_> (I'm operating over ssh/vnc) [20:51:08 CET] <thebombzen_> and I'd lose graphical vnc access if necessary [20:51:30 CET] <thebombzen_> rebooting doesn't have the same issue because I use PAM to do the initial login so I bypass that problem. [20:52:58 CET] <BtbN> yes, an X restart is required as well [21:04:16 CET] <thebombzen_> well restarting X is best done as rebooting [21:04:21 CET] <thebombzen_> because I use lightdm [21:04:43 CET] <furq> doesn't restarting lightdm restart x [21:05:16 CET] <johnnie> can you tell me how to install as a depedency in FF Multi Convert please? [21:05:26 CET] <durandal_1707> no [21:17:58 CET] <SpeakerToMeat> When outputing to discrete frame files, with this syntax: "Filename_%06d.dpx" is there any way to make the index for the number start at possition X ? [21:18:58 CET] <jkqxz> -start_number X [21:19:17 CET] <SpeakerToMeat> thanks jkqxz [21:51:11 CET] <faLUCE> DHE: thnks [22:08:12 CET] <faLUCE> DHE and others: is it possible to get the keyframe/not keyframe info from an AVPacket struct? Should I check the "flags" field? [22:31:23 CET] <madguy02_> hii, i wanted to know,how do i get started with ffmpeg? [22:37:38 CET] <llamapixel> madguy02_: google ffmpeg basics [22:37:58 CET] <llamapixel> the keycorner.org link isnt bad [22:47:10 CET] <grym> llamapixel: what a weird place to put ffmpeg docs [23:16:17 CET] <_jam> is there a way to get ffmpeg to print the libmp3lame version? [23:16:54 CET] <_jam> -version does not include libmp3lame in the list of library versions printed [23:21:23 CET] <DHE> if it's a dynamic link against mp3lame, you can check with `ldd` to see what it's linked against and check it [23:33:28 CET] <_jam> on my debian system, i know how to do that with apt, but i was hoping for a more robust method [23:33:48 CET] <_jam> platform independent and all [00:00:00 CET] --- Sun Mar 5 2017

1 0

ffmpeg-devel.log.20170303
by burek 04 Mar '17

04 Mar '17

[00:01:08 CET] <durandal_170> unholy_me: filter initialization and parameters checking [00:01:54 CET] <durandal_170> unholy_me: search tree there is doc about writing new filters [00:04:26 CET] <unholy_me> ok found it [00:04:32 CET] <unholy_me> it is at dead bottom [00:05:10 CET] <unholy_me> i wanted to ask about this af_pan [00:05:23 CET] <unholy_me> is this only working on one channel? [01:04:05 CET] <cone-768> ffmpeg 03Michael Niedermayer 07master:4b72d5cd6f93: avcodec/mjpegdec: Fix runtime error: left shift of negative value -511 [01:04:05 CET] <cone-768> ffmpeg 03Michael Niedermayer 07master:3b0b35150df4: avcodec/mpegaudiodec_template: Fix runtime error: signed integer overflow: 2053224902 + 2053224902 cannot be represented in type 'int' [01:04:05 CET] <cone-768> ffmpeg 03Michael Niedermayer 07master:6191198c216e: avcodec/interplayvideo: Fix timeout from lack of bitstream end check [01:04:05 CET] <cone-768> ffmpeg 03Michael Niedermayer 07master:55196e5d10af: Revert "avutil/frame: Disallow zero sized frame side data" [01:04:33 CET] <unholy_me> ok i finally created my own filter [01:05:18 CET] <unholy_me> now how are we handling multiple channels? [02:05:51 CET] <cone-768> ffmpeg 03Carl Eugen Hoyos 07master:9ae762da7e25: lavf/matroska: Support codec ID V_FFV1 for demuxing. [09:09:28 CET] <wm4> going to push those filter merger patches [09:09:32 CET] <wm4> anyone want to stop me? [09:09:38 CET] <wm4> you have 10 mins or so [09:10:34 CET] <nevcairiel> did you get the crashing sample from michael [09:13:43 CET] <wm4> yes [09:15:11 CET] <nevcairiel> i assume its fixed by the top commit in your branch? [09:15:23 CET] <wm4> yes [09:15:37 CET] <wm4> just repushed the newest version [09:17:41 CET] <nevcairiel> no complaints from me then [09:30:01 CET] <cone-574> ffmpeg 03wm4 07master:33580a8625c7: ffmpeg: make sure packets put into the muxing FIFO are refcounted [09:30:01 CET] <cone-574> ffmpeg 03Anton Khirnov 07master:4ee5aed122ba: ffmpeg: do packet ts rescaling in write_packet() [09:30:01 CET] <cone-574> ffmpeg 03Anton Khirnov 07master:af1761f7b5b1: ffmpeg: init filtergraphs only after we have a frame on each input [09:30:01 CET] <cone-574> ffmpeg 03wm4 07master:97614a68e474: ffmpeg: fix printing of filter input/output names [09:30:01 CET] <cone-574> ffmpeg 03Anton Khirnov 07master:cb884f8d7e3b: ffmpeg: move flushing the queued frames to configure_filtergraph() [09:30:02 CET] <cone-574> ffmpeg 03Anton Khirnov 07master:76e13bdeaabc: ffmpeg: restructure sending EOF to filters [09:30:02 CET] <cone-574> ffmpeg 03Timo Rothenpieler 07master:736f4af4fea4: ffmpeg_cuvid: adapt for recent filter graph initialization changes [09:30:03 CET] <cone-574> ffmpeg 03wm4 07master:7dd44cde2abb: ffmpeg: delay processing of subtitles before filters are initialized [09:30:03 CET] <cone-574> ffmpeg 03wm4 07master:16abc10b0997: ffmpeg: properly cleanup filter graph on init failure [09:44:58 CET] <ubitux> nice [09:45:08 CET] <ubitux> thx wm4 [09:46:12 CET] <mateo`> thanks :) [09:46:15 CET] <ubitux> wm4: so, how many commits can we skip in the next merge? [09:46:53 CET] <wm4> I don't know, those were 4 merged commits [09:47:09 CET] <ubitux> we're almost at 1k commits to merge [09:47:21 CET] <wm4> I'll probably look at the hwaccel threading ones next (at least those are pretty self-contained) [09:49:55 CET] <ubitux> wm4: you're not going to like the last mail from Carl, i'm sorry [09:50:14 CET] <ubitux> i'm calling for ignoring him [09:54:46 CET] <mateo`> seriously ? [09:55:33 CET] <mateo`> what he is trying to achieve there ... [09:55:35 CET] <wm4> "braking" [09:55:38 CET] <wm4> so I'm slowing him down? [09:59:12 CET] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-February/207648.html damnit i missed that one too [10:12:07 CET] <wm4> that last case, dvbsubtest.ts, actually works now with my patches applied if the target container is mkv [10:12:19 CET] <ismail> Compn: done, thanks! [10:12:28 CET] <wm4> it failed with "Application provided invalid, non monotonically increasing dts" before [12:29:24 CET] <cone-574> ffmpeg 03Paul B Mahol 07master:6d93e7d1a3e6: avcodec/scpr: fix top left prediction for special case when x is 0 for keyframes [15:14:58 CET] <J_Darnley> Is it worthwhile making and submitting a couple of patches to change/fix cosmetic issues in libavcodec/h264idct_template.c? [15:17:31 CET] <jamrial> if they change one or two lines then no, but if you're reindenting a lot of things or such then yes [16:02:33 CET] <J_Darnley> Ha ha ha damn! What did I do to make ffmpeg crash in libc's malloc_consolidate? [16:02:38 CET] <J_Darnley> Come here valgrind [16:02:44 CET] <JEEB> sounds like fun :D [16:06:51 CET] <J_Darnley> Hm. Invalid write of 8 in ??? [16:10:48 CET] <BBB> youre writing past buffer size i think [16:10:53 CET] <BBB> in your assembly [16:11:27 CET] <J_Darnley> Yeah, but the stack doesn't look like where the function I was working on is called [16:12:00 CET] <J_Darnley> But it is caled though a function pointer passed at from at least 3 functions higher [16:12:29 CET] <BBB> try asan [16:12:37 CET] <BBB> asan detects stack overwrites better than valgrind [16:13:06 CET] <J_Darnley> Thanks. I'll do that after valgrind finished running with my function removed [16:25:25 CET] <J_Darnley> Why on earth am I doing that on my cheap(ish) laptop when I could be doing it on a big and powerful server? [16:26:01 CET] <nevcairiel> convenience of local work? [16:26:08 CET] <J_Darnley> Indeed [16:27:32 CET] <jkqxz> The big and powerful server doesn't have AVX2? [16:29:36 CET] <jkqxz> The bigger Intel cores lagging behind on features like that is kindof annoying, though maybe AVX-512 is indicating a change of strategy there. [16:30:44 CET] <J_Darnley> Meh, a way to cut up their offering to maximise profit I guess. [16:32:52 CET] <nevcairiel> AVX2 is old enough by now, though [16:34:04 CET] <nevcairiel> anyhow the bigger cores don't necessarily lag behind in features, they just generally lag behind in release dates. It takes often over a year for the big variants of a chip to be released, with the same features as the consumer variant then. [16:35:22 CET] <J_Darnley> What I am most gutted about is their low end ones not having avx/avx2. I want avx and ecc on the cheap. [16:35:41 CET] <nevcairiel> dont you have to go very low end for those to be cut out [16:35:57 CET] <nevcairiel> thats basically atom cores then isnt it, no wonder, different core entirely =p [16:36:07 CET] <J_Darnley> avx is missing in pentium and celeron, but those both have ecc [16:36:22 CET] <nevcairiel> they make ecc pentiums and celerons? [16:36:23 CET] <jkqxz> No, you have to go low-end for ECC on consumer cores (don't want to eat into the server market). [16:36:38 CET] <jkqxz> Core iN no longer has ECC anywhere. [16:36:45 CET] <nevcairiel> low-end e3 cpus are usually not that expensive [16:36:58 CET] <nevcairiel> do they even have consumer mainboards with ecc support [16:37:44 CET] <J_Darnley> Allegedly [16:38:00 CET] <J_Darnley> Not the registered kind [16:38:18 CET] <nevcairiel> thats only supported in xeons anyway, isnt it [16:38:36 CET] <nevcairiel> and e5 and above only [16:38:41 CET] <nevcairiel> (ie. the proper xeons) [16:39:44 CET] <nevcairiel> cheapest skylake xeon e3 is 190¬, not that bad, but still more then some pentium i guess [16:41:37 CET] <J_Darnley> That seems pretty reasonable. [16:42:54 CET] <jkqxz> Still more than twice the price of the most expensive pentium (which has fewer but faster cores, uses less power, and has free graphics for extra floppiness should you be that way inclined). [16:43:53 CET] <nevcairiel> could pay 30 or so more for the igpu [16:44:20 CET] <J_Darnley> I was eyeing the G3930 or G4650 for ~¬40 and ~¬60 [16:44:29 CET] <nevcairiel> it seems odd that they allow the pentiums and celerons to have ecc [16:44:36 CET] <nevcairiel> seems like a odd feature to have in those [16:44:55 CET] <J_Darnley> Maybe the low power T variant if they become available [16:45:07 CET] <nevcairiel> dont those typically even cost more [16:45:12 CET] <nevcairiel> just buy a normal and downclock it =p [17:07:53 CET] <J_Darnley> Oh cock. fate needs the lavfi input "device" [17:13:09 CET] <nevcairiel> yeah its used to generate test data [17:13:50 CET] <J_Darnley> I guess I was just surprised to learn that it is a device [17:14:06 CET] <nevcairiel> you might as well call it a "demuxer" [17:14:12 CET] <nevcairiel> none of the words fit very well [17:14:51 CET] <J_Darnley> Meh. It is a device because ffmpeg/configure calls it a device. [17:18:38 CET] <cone-574> ffmpeg 03Takayuki 'January June' Suwa 07master:13332504c989: omx: Add support for specifying H.264 profile [v5'] [17:18:39 CET] <cone-574> ffmpeg 03Michael Niedermayer 07master:d8094a303ba3: avcodec/vp3: Do not return random positive values but the buf size [17:24:18 CET] <Guest7213> durandal_1707: I have re-forked, applied patch, and freshly compiled the FFmpeg repository, please tell what I should do next? [17:25:21 CET] <durandal_1707> does it displays xpm with ffplay? [17:26:00 CET] <durandal_1707> patebin output of git diff master [17:26:28 CET] <adeeln_> durandal_1707: okay [17:30:50 CET] <adeeln_> durandal_1707: Here is the output of 'git diff master': https://gist.github.com/adl1995/a9d78dc9de8891582854ef669c558c8f [17:32:28 CET] <durandal_1707> adeeln_: you forgot to add libavcodec/xpmdec.c to your branch [17:32:38 CET] <durandal_1707> same for xpmenc.c [17:35:09 CET] <adeeln_> durandal_1707: oh, I didn't commit. Do I commit to the same master branch (just want to be sure). [17:38:31 CET] <cone-574> ffmpeg 03James Almer 07master:e2b7ae4b198c: avutil/md5: fix misaligned reads [17:38:32 CET] <cone-574> ffmpeg 03James Almer 07master:a43389547c51: avutil/md5: stop discarding the const qualifier for the src pointer [17:40:40 CET] <Miles> Anyone here involved in user documentation? Noticed an ommission for the flac encoder. [17:41:22 CET] <Miles> The numeric range for compression_level isn't mentioned which is kind of important since the one in ffmpeg goes from 0-12 unlike every other encoder. [17:42:31 CET] <durandal_1707> adeeln_: do not touch master branch [17:42:50 CET] <durandal_1707> adeeln_: on which branch you are working? [17:44:36 CET] <adeeln_> durandal_1707: I've added the patch on master branch, but I haven't commited yet. [17:44:53 CET] <adeeln_> durandal_1707: should I create a new branch? [17:45:00 CET] <jamrial> Miles: thanks, will fix that [17:46:13 CET] <Miles> jamrial: Cool, thanks for looking into it. Just to be clear I mean over here but it may be missing in other relevant places too [17:46:13 CET] <Miles> https://ffmpeg.org/ffmpeg-codecs.html#flac-2 [17:46:37 CET] <Miles> Actually I don't thin -h encoder=flac mentions the compression_level parameter at all let alone a range [17:47:03 CET] <jamrial> that's because compression_level is a generic option used by many encoders [17:47:25 CET] <jamrial> it's not specific to flac [17:47:37 CET] <nevcairiel> its an unfortunate limitation of our option system [17:47:48 CET] <Miles> But it has different meanings and valid ranges for different encoders? Seems worth putting in the encoder command line help. [17:47:52 CET] <Miles> Oh I see. [17:48:26 CET] <nevcairiel> global options that are re-used by many things dont get codec-specific docs [17:50:00 CET] <Miles> Where can I learn more about why it goes to 12 and what each preset does? flacenc.c in libavcodec didn't tell me a whole lot. [17:50:21 CET] <cone-574> ffmpeg 03James Almer 07master:68ee800a9dd9: doc/encoders: mention valid values for compression_level when using FLAC encoder [17:51:42 CET] <nevcairiel> the code basically has it, but its not documented i dont think [17:52:03 CET] <nevcairiel> changes block size, lpc type, min/max prediction order, and prediction order method [17:52:15 CET] <nevcairiel> oh and partition order [17:52:54 CET] <Miles> Can I assume 12 is technically most efficient if not overkill? [17:53:04 CET] <nevcairiel> http://pastebin.com/4nNjhU14 this basically, level is always an index into the tables [17:53:20 CET] <jamrial> flac is so fast that no matter what you choose it will never be overkill [17:53:31 CET] <nevcairiel> unless you u se the alien mode [17:53:44 CET] <nevcairiel> (multi_dim_quant) [17:53:46 CET] <nevcairiel> it can get slow [17:54:55 CET] <durandal_1707> adeeln_: if your current branch is master, create new branch [17:54:57 CET] <Miles> Oh the source is making a little more sense to me now, I see those 12-arrays corresponding to compression level. [17:56:14 CET] <Miles> Thanks nevcairiel and jamrial, I think I'm good for now. [17:57:19 CET] <adeeln_> durandal_1707: okay, creating new branch and commiting to it. [17:58:13 CET] <jamrial> Miles: but yes, 12 is best compression [17:58:47 CET] <jamrial> it is considerably slower than 0, admitedly, but only for encoding [17:59:01 CET] <jamrial> there doesn't seem to be a difference when decoding the resulting files [18:01:48 CET] <Miles> jamrial: Ok [18:07:43 CET] <durandal_1707> adeeln_: now commit changes in it and paste diff [18:12:31 CET] <adeeln_> durandal_1707: just did, please check: https://gist.github.com/adl1995/5b3f681ba2c710915cc6cf567d3cdb83 [18:28:23 CET] <J_Darnley> Can someone help me understand this message from gcc asan? http://pastebin.com/Ah1PYkpb [18:28:48 CET] <J_Darnley> Can I have it print function names? [18:46:37 CET] <kierank> J_Darnley: you have to use asan symboliser [18:52:54 CET] <atana> michaelni, in ff_generate_window_func (float *lut, int N, int win_func, float *overlap) win_func -> WFUNC_HAMMING what other parameters refers to? is there any example where is it used? [18:53:27 CET] <kierank> J_Darnley: 5:46 PM <"kierank> J_Darnley: you have to use asan symboliser [18:56:03 CET] <michaelni> atana, you can find occurances / uses of something with git grep ff_generate_window_func [18:56:36 CET] <atana> ok [19:34:38 CET] <JEEB> wm4: did your merge move the initialization of encoders later? [19:35:08 CET] <JEEB> so in theory now in ffmpeg.c some stuff like utvideo.c might be able to get the colorimetry as it's already available @ init() [19:35:15 CET] <JEEB> *utvideoenc.c [19:43:50 CET] <nevcairiel> yes JEEB [19:44:39 CET] <JEEB> \o/ [19:48:51 CET] <J_Darnley> kierank: thank you [19:52:42 CET] <JEEB> hmm [19:52:52 CET] <JEEB> well, seems like I am not getting love yet [19:52:59 CET] <JEEB> with 68ee800 [19:53:24 CET] <nevcairiel> maybe the info is lost in a filter or something? [19:53:33 CET] <nevcairiel> it sh ould create the encoder only after decoding a input frame [19:53:35 CET] <nevcairiel> so it has all info [19:54:46 CET] <JEEB> http://up-cat.net/p/e125038d [19:55:32 CET] <JEEB> it should pick !ULY0 in case of BT.709 [19:55:41 CET] <JEEB> so during init() it still doesn't have the colorimetry [19:55:53 CET] <JEEB> (pretty much a special case where the container contains the darn metadata) [20:06:26 CET] <jkqxz> JEEB: That information is on the frames, not the codec? I don't think anything in the change actually picks that metadata off the frame itself. [20:07:22 CET] <JEEB> not sure which value I used in init() (where that has to be set so it gets passed onto the AVI muxer early enough) [20:07:27 CET] <JEEB> let me check [20:07:46 CET] <JEEB> yeah, avctx->pix_fmt [20:07:57 CET] <JEEB> as you only start getting frames @ process_frame() [20:08:07 CET] <jkqxz> The stream is initialised when you have output from the decoder, but before you pick the first frame from the filter graph <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg.c;h=db7e8cd0c6723bbde…>. [20:09:07 CET] <jkqxz> So the extra parameters you are gaining here are from the decoder context, but any which only got attached to the individual frames will be lost. [20:09:47 CET] <jkqxz> Well, not lost: are still missing. [20:11:20 CET] <jkqxz> It would take a bit more work to push the output stream initialisation back even further, so that you have the first frame from the filter graph available as well and can use the colour information from it. [20:12:19 CET] <JEEB> hmm, I don't think there was a filter in the middle [20:12:25 CET] <JEEB> it was just yuv420p to yuv420p [20:17:23 CET] <jkqxz> You get a filter graph anyway in transcode. [20:17:31 CET] <JEEB> right [20:18:53 CET] <nevcairiel> I thought things are actually initialized from the frame themself [20:18:55 CET] <nevcairiel> not from any context [20:19:04 CET] <nevcairiel> so you would need to have some kind of frame done already [20:19:46 CET] <adeeln_> durandal_1707: please check: https://gist.github.com/adl1995/5b3f681ba2c710915cc6cf567d3cdb83 [20:19:48 CET] <jkqxz> That's the input to the filter attached to the output stream. [20:20:16 CET] <JEEB> in formats where the initialization of colorspace information is coded into the video stream itself it can be in the actual encode() calls [20:20:36 CET] Action: JEEB wonders why umezawa went for separate fourccs instead [20:42:44 CET] <J_Darnley> Ugh. I'm sure it is user error but I think this asan stuff is rubbish. [20:42:47 CET] <J_Darnley> I have no idea what its doing and most of my searches get corrected into "asian symbol". [20:44:19 CET] <nevcairiel> JEEB: guess that information isnt actually transfered to an encoder, ffmpeg.c would probably need to explicitly do that somehow [20:46:18 CET] <nevcairiel> but it can do that now! [20:46:28 CET] <JEEB> yea [20:46:35 CET] <JEEB> totally a step to a better future [20:56:55 CET] <atomnuker> I need ideas for a gsoc project [20:57:58 CET] <jamrial> improvements to your opus encoder? [20:58:10 CET] <michaelni> Ive sent invites for gsoc mentoring to everyone listed on the ideas page, if someone has been missed ping me, if someone is added to the page and needs a invite ping me [20:59:17 CET] <jamrial> make the vorbis encoder not suck. make the dca encoder not suck and also write bitexact dts-ma streams (maybe also other extensions like dts-es or dts-hra) [20:59:26 CET] <jamrial> fix the truehd encoder so it's actually bitexact [20:59:40 CET] <michaelni> also i need a backup mentor for "Minterpolate improvments" (DSM might be the student for this one) [21:03:43 CET] <atomnuker> jamrial: danail's already working on the dca encoder, so I guess I'll put both truehd and vorbis up there [21:15:36 CET] <jamrial> atomnuker: the truehd encoder is recent and supposedly has a maintainer (one of the two authors), so probably better poke them about it first [21:16:28 CET] <atomnuker> yeah, only listed the vorbis one [21:16:53 CET] <atomnuker> also I'm not sure that it deserves an entire gsoc project since I think its a one line fix somewhere [21:30:35 CET] <ember3> is the motion vector computation approach in https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/extract_mvs.c as fast as could be expected? it runs at only 2.9x realtime [21:32:26 CET] <ember3> (also notice it's using many deprecated things like avcodec_decode_video2) [21:33:50 CET] <wm4> yeah, the examples and even ffmpeg.c have a bad track record at using deprecated APIs [21:34:18 CET] <ember3> presumably it should be consuming avcodec_receive_frame [21:34:31 CET] <wm4> yes [21:34:50 CET] <ember3> would there be a dramatic speed difference? [21:34:51 CET] <wm4> OTOH the deprecated one will still work for a long time [21:34:54 CET] <wm4> no [21:35:13 CET] <wm4> could even get slower if you e.g. don't pass a refcounted input buffer (to ...send_packet) [21:35:20 CET] <ember3> really don't understand why it's so slow, haven't started digging through the internals yet [21:35:42 CET] <wm4> probably because it decodes the whole video? whatever you're doing [21:38:17 CET] <ember3> wall clock of 2.9x is on the example, reading a 41mb mp4 and writing to /dev/null [21:44:30 CET] <ubitux> ember3: yes it needs to decode the video to extract the mvs [21:45:06 CET] <ubitux> at some point it was considered to skip the idct etc, but it required hacking quite excessively the decoder [21:45:22 CET] <ubitux> and you won't be able to skip the entropy step anyway [21:48:12 CET] <ember3> will it in theory run the decoding through hwaccel if hardware is available? [21:49:35 CET] <JEEB> uhh [21:49:41 CET] <JEEB> how do you get that data from a hw decoder? [21:49:52 CET] <JEEB> it's stuff that is explicitly gotten from the insides of that decoder [21:50:11 CET] <JEEB> so unless you get such surgical access into the internals of a hw decoder then there's no way of doing that [21:52:10 CET] <ubitux> using hwaccel means you're skipping the software decoding so you won't get the mvs as they are obtained from the software decoder [21:52:28 CET] <ubitux> so hw decoder seems to expose them somehow, i think there was some rpi/android crap stuff about this [21:52:35 CET] <ubitux> some* [21:52:41 CET] <ubitux> but not supported in ffmpeg [21:52:48 CET] <ember3> you can get that out as side information.. [21:52:50 CET] <ember3> https://www.raspberrypi.org/blog/vectors-from-coarse-motion-estimation/ [21:52:51 CET] <ember3> yeah [21:52:53 CET] <ubitux> (not the rpi accel. the mvs exposition) [22:30:05 CET] <DSM_> ubitux: as hwaccel don't give motion vectors, how about using a filter for mvs [22:30:08 CET] <DSM_> https://ffmpeg.org/ffmpeg-filters.html#mestimate [22:30:37 CET] <JEEB> ember3 was trying to get the coded vectors :P [22:31:09 CET] <DSM_> okay [22:31:11 CET] <ember3> I really just want the lowest motion frames within a time interval [22:31:13 CET] <wm4> DSM_: how does this compare to mvtools anyway? [22:31:28 CET] <ubitux> DSM_: mestimate is not mature enough; last time i tried it was slow and had bad results [22:31:29 CET] <ember3> seems like working from motion vectors would be simplest [22:32:16 CET] <ubitux> DSM_: also, i suppose it's in the context where you don't have the necessary computing resources available so you want to reuse mvs to have a quick & dirty result [22:33:38 CET] <wm4> yeah, codec mvs can apparently be bad for motion estimation, since they optimize for reducing redundancy, not detecting motion [22:33:42 CET] <ubitux> so reusing already estimated data is a good idea, but in practice if your platform don't have much processing resources, it's likely it won't have enough to software decode the video [22:33:45 CET] <JEEB> wm4: yup [22:33:47 CET] <wm4> so the mvs can be all over the place [22:38:40 CET] <ember3> wm4: has that effect been formally characterized somewhere? motion visualizations from codec mvs are pretty compelling to the naked eye [22:43:31 CET] <jkqxz> The best result is very bitrate-dependent. At low bitrates you end up smoother than reality, because the motion is predicted from nearby motion (spatial, also temporal in newer codecs) and therefore it minimises bit use to just take the prediction and use it (possible with some of fudging of the residuals). [22:43:54 CET] <ubitux> it depends on the encoder and its options too [22:44:09 CET] <jkqxz> At high bitrates the opposite happens - since the motion encoding is much less significant, you place it minimise residuals and fuck how well it matches the prediction. [22:44:12 CET] <ubitux> you'll have frame with no mvs btw [22:44:39 CET] <ubitux> if you have computing power, you better go for your own optical flow [22:45:17 CET] <ubitux> if you're on embedded devices i'd actually also be tempted to go in something similar exploiting at best the hw chip available [22:45:47 CET] <ubitux> mvs from ffmpeg are ok for experimenting but the main goal is debugging (see codecview filter) [22:51:14 CET] <DSM_> ubitux: i don't know how fast hwaccel decoding + mestimate can be compared to software decoding. of course choice depends on application. mestimate uses motion_estimation.c functions, which were intended to be used in both filters and codecs [22:51:28 CET] <DSM_> can you please suggest to make them more mature? [22:52:17 CET] <ubitux> DSM_: nothing more than what i raised on the ml [22:52:23 CET] <DSM_> apart from speed optimizations [22:53:04 CET] <ubitux> apart from speed the mvs where not convincing at all; i remember sharing a sample [22:53:10 CET] <ubitux> or two [22:53:51 CET] <ubitux> anyway, if you use hw decoding on embedded system, you likely want to avoid going back to cpu world [22:57:16 CET] <DSM_> ubitux: on ml? on motion interpolation thread iirc? [22:57:32 CET] <ubitux> yes, iirc you even answered [22:58:25 CET] <DSM_> yeah :D probably it [22:58:37 CET] <DSM_> *it's because of penalty [22:58:42 CET] <philipl> BtbN: do you have an opinion on the nvenc constant quality question I asked? p vs b vs i values? [22:59:11 CET] <BtbN> The one weather the values for p/b should differ from the I one? [23:01:54 CET] <BtbN> I don't really have an idea what's the right solution there. [23:24:13 CET] <philipl> Yeah, that one. [00:00:00 CET] --- Sat Mar 4 2017

1 0

ffmpeg.log.20170303
by burek 04 Mar '17

04 Mar '17

[00:19:54 CET] <peetah> ok after some more search, it seems the problem may come from visioforge which is used by their software [00:20:34 CET] <peetah> they state that ffmpeg is dual licenced LGPL and GPL, but choose LGPL : http://visioforge.com/support/717091-Decoding-in-Video-Edit-SDK-with-FFMPEG [00:21:26 CET] <peetah> this seems plain wrong to me, but the message is from 2013, so I don't know what was the licence status then [00:22:04 CET] <JEEB> if they have compiled FFmpeg with --enable-gpl then that's a specific wish to utilize functionality that makes the license become GPL [00:22:15 CET] <JEEB> LGPL is the default [00:26:53 CET] <peetah> so it seems visioforge is the infringer and the software I'm talking about, and all the visioforge clients, just a collateral victim of visioforge poor choices [01:09:56 CET] <MastaG> Hi, I'm reading up on the wiki on how to use the hls segmenter [01:10:23 CET] <MastaG> I'm trying to transcode and transmux a live stream from tvheadend and publish it [01:10:30 CET] <MastaG> Here's my paste: http://pastebin.com/F7hByLfQ [01:11:13 CET] <MastaG> Error while opening encoder for output stream #0:2 - maybe incorrect parameters such as bit_rate, rate, width or height [01:11:33 CET] <MastaG> Whats wrong with it? Stream #0:2 -> #0:2 (dvb_teletext (libzvbi_teletextdec) -> webvtt (native)) [01:13:31 CET] <llogan> show the *complete* output [01:13:39 CET] <DHE> MastaG: you've got a typo. -hls_list_size size 10 [01:13:49 CET] <DHE> you've confused it [01:18:05 CET] <DHE> MastaG: got it? [01:21:15 CET] <MastaG> yeah [01:21:31 CET] <MastaG> Here's the complete output: http://pastebin.com/nLr1ZvT8 without the size typo [01:21:59 CET] <MastaG> I wonder what options I'm missing for the encoding of subtitles [01:25:08 CET] <MastaG> I mean it already suggests to re-encode the subs from dvb_teletext to webvtt... [01:25:37 CET] <MastaG> And the wiki does not specify a filename for the webvtt subs either [01:33:31 CET] <MastaG> llogan: would you happen to find anything? [01:37:26 CET] <MastaG> well I can also drop the subtitle track with -sn I guess.. [01:37:46 CET] <llogan> i stopped looking when i noticed you used -loglevel debug. it's too verbose [01:37:55 CET] <MastaG> oh [01:38:43 CET] <MastaG> well nm.. I'm not mapping the dvb subtitle track anymore.. so it works [02:51:09 CET] <thebombzen_> does anyone know an easy way to turn a time duration into "seconds" [02:51:13 CET] <thebombzen_> like a oneliner [02:53:18 CET] <blb> thebombzen_: like, in code? [02:53:27 CET] <thebombzen_> well yea [02:54:13 CET] <thebombzen_> I haven't found an easy oneliner for everything, because the number of colons can vary. it could be h:m:s or m:s or just s [02:57:17 CET] <thebombzen_> welp, apparently if you use the improved cut it's easy [03:00:46 CET] <furq> what did you do [03:05:07 CET] <thebombzen_> with improved cut, it's just: cuts -d':' -1 -2 -3 | awk '{ print $1 + (60 * $2) + (3600 * $3) }' [03:05:13 CET] <thebombzen_> perhaps there's a way to do it in pure awk tho [03:06:28 CET] <furq> what's "improved cut" [03:10:01 CET] <tdr> not sure that would work if there was only like 2 field (minutes and second) since $1 would be minutes vs hours and the seconds would get multilied by 60 not 360 [03:10:08 CET] <tdr> 3600 [03:10:49 CET] <thebombzen_> oh it's the cuts command [03:10:52 CET] <thebombzen_> it's like cut but doesn't suck [03:11:28 CET] <thebombzen_> tdr: it does because cuts counts from the end. if you give that awk command no "hours" field it'll assume it's empty [03:11:45 CET] <furq> http://vpaste.net/xPqBx [03:11:49 CET] <furq> there's my shitty attempt anyway [03:11:50 CET] <thebombzen_> and when it does the string->int conversion to multiply by 3600, it should work [03:12:03 CET] <thebombzen_> I did figure it out with pure awk tho [03:12:04 CET] <thebombzen_> wk -F: '{for (i=NF; i>1; i--) printf "%s%s", $i, FS; print $i }' | awk -F: '{ print $1 + (60 * $2) + (3600 * $3) }' [03:12:05 CET] <tdr> hrm, awk could for sure do it too, you could code a payroll system with awk [03:12:15 CET] <furq> that's with awks, not awk [03:12:18 CET] <furq> get on my level [03:12:20 CET] <thebombzen_> the hard part was reversing the fields [03:12:47 CET] <thebombzen_> ah your method is better [03:13:20 CET] <furq> you're a two awks on your shoulders kind of guy [03:14:33 CET] <thebombzen_> yea whereas your prefer to be one big tots awk [03:15:03 CET] <thebombzen_> although I do not actually say "tots awk" out loud because that would be tots awk [03:22:53 CET] <thebombzen_> lol look at all the wrong answers to this question: https://stackoverflow.com/questions/6239350/how-to-extract-duration-time-fr… [04:01:49 CET] <RossW> llogan/fflogger, either of you watching? [04:02:53 CET] <k_sze[work]> Is it acceptable for two JPEG decoders to decode an image to slightly different results? [04:03:00 CET] <RossW> Wanted to send a big Cheers! and thanks to you guys for pointing pointing me in the right directions yesterday. [04:03:08 CET] <k_sze[work]> I can understand if two JPEG encoders *encode* differently. [04:03:19 CET] <RossW> Updated to ffmpeg version 3.2.4 (may not be the latest but it does). [04:03:50 CET] <k_sze[work]> But shouldn't decoding be deterministic, barring postprocessing? [04:03:58 CET] <RossW> Realized that there was a fundamental flaw in the idea of using timecode or frame*interval+offset, because there was always the chance I had missing stills [04:04:16 CET] <c_14> k_sze[work]: many codecs aren't bitexact decodable [04:04:24 CET] <c_14> especially jpeg what with embedded color profiles and whatever [04:05:33 CET] <RossW> In the end, I wrote a script that writes a subtitle file, with the exact format (HH:MM) I want, keyed to the output video (so new subtitle every 40ms). [04:05:33 CET] <tdr> k_sze[work], the spec doesnt say they are required to produce bit by bit identical output. png would but not all the time with jpeg [04:06:06 CET] <k_sze[work]> I see. [05:55:23 CET] <YellowberryHN> How does one play an mp3 file from the terminal? [06:02:50 CET] <furq> YellowberryHN: ffmpeg -i foo.mp3 -f alsa hw:0 [06:03:51 CET] <furq> although if you plan on doing this regularly, you probably want a proper player like mpd/moc/xmms2 [06:08:29 CET] <YellowberryHN> right [06:08:56 CET] <YellowberryHN> writing a diagnostic script to test aspects of a server [06:09:06 CET] <YellowberryHN> using that to test sound output [06:09:13 CET] <YellowberryHN> if it's detected [06:11:02 CET] <YellowberryHN> furq: "Requested output format 'alsa' is not a suitable output format" [06:12:03 CET] <furq> what os [06:12:26 CET] <furq> if it's a headless *nix server then you probably don't have alsa installed, or didn't when ffmpeg was built [06:12:46 CET] <YellowberryHN> I have alsa installed [06:13:20 CET] <YellowberryHN> posible that it wasn't built with alsa support [06:13:26 CET] <furq> ffmpeg -devices [06:14:14 CET] <YellowberryHN> Missing argument for option devices [06:14:43 CET] <furq> uh [06:14:47 CET] <furq> what version of ffmpeg is that [06:15:47 CET] <YellowberryHN> ffmpeg version 0.8.20-6:0.8.20-0+deb7u1 [06:15:58 CET] <furq> oh wow that's ancient [06:16:00 CET] <furq> is that debian wheezy [06:16:14 CET] <YellowberryHN> yeah.... [06:16:21 CET] <furq> fun [06:16:34 CET] <furq> https://www.johnvansickle.com/ffmpeg/ [06:16:51 CET] <furq> i forget if those builds have alsa support [06:16:58 CET] <furq> you might need to build it yourself if they don't [06:16:59 CET] <YellowberryHN> oh yeah [06:17:04 CET] <YellowberryHN> forgot to mention [06:17:09 CET] <YellowberryHN> armhf processor [06:17:17 CET] <furq> there are armhf builds on there [06:17:19 CET] <YellowberryHN> probably why it's ancient [06:17:23 CET] <YellowberryHN> oh ok [06:18:58 CET] <furq> tbh it might be easier to just use sox [06:19:15 CET] <furq> wheezy has libsox-fmt-all which adds mp3 playback [06:22:42 CET] <YellowberryHN> That worked, thank you very much [06:22:51 CET] <YellowberryHN> maybe I should update my debian [06:22:56 CET] <YellowberryHN> nah.. [06:23:00 CET] <YellowberryHN> thanks again [06:23:02 CET] <furq> what worked, sox or the static ffmpeg? [06:23:03 CET] <YellowberryHN> bye! [06:23:06 CET] <YellowberryHN> sox [06:23:19 CET] <furq> fair enough [06:23:20 CET] <YellowberryHN> ffmpeg refused to run [06:23:51 CET] <YellowberryHN> I think my download was corrupted somehow because it segfaulted [06:24:27 CET] <YellowberryHN> anyway, gotta jet, thanks again [11:57:48 CET] <styler2go> How can i reduce the video size by percentage? [12:18:17 CET] <dl2s4> styler2go, i guess two pass x264 could aim for specific filesize with a bit calculation. iirc [12:18:33 CET] <styler2go> sorry, i ment resolution :/ [12:18:39 CET] <styler2go> Always forget size != resolution [12:22:45 CET] <dl2s4> you could use -s <final_reslution> [12:31:29 CET] <jkqxz> styler2go: -vf scale=iw*70/100:-2 [12:32:50 CET] <dl2s4> this would scale it down 70%? [12:33:39 CET] <jkqxz> To 70% of current size. [12:35:29 CET] <dl2s4> ah yeah, what i meant :) and why -2? [12:37:10 CET] <dl2s4> i investigated a bit and it seems -1 means to keep aspect ratio [12:39:14 CET] <jkqxz> Because lots of things barf on sizes which aren't divisible by 2. [12:39:50 CET] <jkqxz> (The first part would probably be better as iw*70/200*2 to match.) [12:41:06 CET] <dl2s4> ah ok, thanks [17:56:03 CET] <alexpigment> does anyone know how to get a list of pix_fmt options in FFMPEG? [17:56:28 CET] <alexpigment> i need to make sure I know which pix_fmt options are specific to the 10-bit version of FFMPEG [17:58:54 CET] <jkqxz> "ffmpeg -pix_fmts"? Though I'm not sure what you mean by a "10-bit version" of ffmpeg. [18:00:35 CET] <alexpigment> awesome. that's what i needed. for context, i have a build of ffmpeg that includes 10-bit x264 and x265. to trigger this, i need to have a list of pix_fmts that are exclusive to each. and when a pix_fmt is specified that is exclusive to 10-bit, it'll switch copies of ffmpeg (which are currently mutually exclusive for some reason) [18:01:55 CET] <kepstin> alexpigment: ffmpeg should support the same pix_fmts in both cases, the difference is in which pix_fmts work with the video encoders... [18:02:10 CET] <alexpigment> yeah, i guess i'm seeing that now :( [18:02:26 CET] <kepstin> (like, you can use 10bit video in an ffmpeg with 8bit x264, and it'll just convert it down to 8bit before encoding) [18:02:42 CET] <alexpigment> well, either way, this list gives me something to work with, since i only need 4:2:0, 4:2:2, and 4:4:4 variants [18:03:00 CET] <alexpigment> kepstin: i specifically need 10-bit output [18:03:05 CET] <alexpigment> because, of course, HDR requires it [18:03:21 CET] <alexpigment> dithering down isn't necessary for my uses [18:03:25 CET] <kepstin> alexpigment: right, so you have 2 ffmpegs, just name one ffmpeg_10 and run it whenever you need 10bit output? [18:03:44 CET] <alexpigment> kepstin, this is for automated use based on a command line [18:04:16 CET] <kepstin> so, how do you know when you need to use 10bit output vs 8bit output? [18:04:18 CET] <alexpigment> but that's certainly a way to do it [18:04:32 CET] <kepstin> is it based on the input file? based on telepathically reading the user's mind? [18:04:43 CET] <alexpigment> keptstin, in my case, i would trigger it based on seeing yuv420p10le, for example [18:04:59 CET] <kepstin> alexpigment: so, if the input is 10bit, you also want 10bit output? [18:05:00 CET] <alexpigment> no, it's going to be piped in from a 10-bit BGRA renderer [18:05:08 CET] <alexpigment> so the input is synthetic [18:05:17 CET] <alexpigment> no transcoding is involved here [18:05:24 CET] <kepstin> if the input's always 10bit, then just always use the 10bit encoder? I don't see the problem here. [18:05:42 CET] <alexpigment> keptstin: 10-bit video is useless as a standard delivery format [18:06:04 CET] <alexpigment> if you want something for blu-ray, web, or just generally playing on your computer, you need 8-bit [18:06:30 CET] <alexpigment> however, if you need 4K HDR, you need 10-bit, as well as all the other special colorspace stuff [18:06:30 CET] <kepstin> alright, so you have two different ffmpegs, you know which is which, and you know whether you want 8 or 10 bit output - so just run the correct one? :/ [18:07:16 CET] <alexpigment> i mean i suppose you have a point. i just planned to approach it differently [18:07:44 CET] <alexpigment> by detecting pix_fmt in the command line parameters and then automatically using a particular variant of ffmpeg [18:08:09 CET] <alexpigment> anyway, we'll see how it shakes out. thanks for the advice [18:08:11 CET] <kepstin> alexpigment: is the user manually running ffmpeg, or is this generated by an application/script? [18:08:19 CET] <alexpigment> the latter [18:08:56 CET] <kepstin> then just have the script choose which ffmpeg based on whether it's doing 10bit or 8bit, simple enough :/ [18:08:56 CET] <alexpigment> aight, i gotta get back to this to finish up. thanks again! [18:09:11 CET] <kepstin> I wouldn't bother trying to parse ffmpeg's command line arguments :) [18:10:42 CET] <kepstin> (i assume you have static ffmpeg builds in this case; if it was dynamic, both ffmpegs would use the same x264 libs and you'd have to play with e.g. LD_LIBRARY_PATH to switch the bitness) [18:11:02 CET] <alexpigment> it's dynamic, actually [18:11:18 CET] <alexpigment> since ffprobe is needed, file size is saved by doing shared [18:11:21 CET] <alexpigment> er [18:11:29 CET] <alexpigment> sorry, it's *shared* [18:11:44 CET] <alexpigment> i don't think the LD_LIBRARY_PATH thing works for Windows, does it? [18:12:07 CET] <kepstin> ah, windows? It should be fine if the ffmpeg binaries are in separate directories, and the shared dlls used are in the same dir [18:12:29 CET] <kepstin> same dir as the executables* [18:13:11 CET] <alexpigment> kepstin - i think i'm missing your point [18:13:21 CET] <alexpigment> do you mind elaborting a little bit so i understand the benefit? [18:14:32 CET] <kepstin> alexpigment: you have ffmpeg.exe, ffprobe.exe along with a set of dlls like libavcodec.dll, libx264.dll, right? [18:14:53 CET] <alexpigment> right [18:15:25 CET] <kepstin> so the only difference between a ffmpeg supporting 10 bit encoding and one doing 8 bit encoding is that the x264 (and x265) dlls are different [18:15:52 CET] <alexpigment> i'm not entirely sure that's true, but yes, most likely [18:16:21 CET] <kepstin> trust me, that's true. you can actually switch it out without rebuilding ffmpeg by just changing the x264/x265 libraries :) [18:17:19 CET] <alexpigment> ok, so how would you call each one separately? [18:17:56 CET] <kepstin> alexpigment: but actually switching the dlls on windows is probably a pain, so I wouldn't do that. Just put the 10bit and 8bit ffmpeg builds each in their own directory [18:18:05 CET] <kepstin> (along with their associated dlls) [18:18:06 CET] <alexpigment> looking at the folder now, it seems that the avcodec-57.dll files are different. i assume those wrap up the encoders [18:18:25 CET] <alexpigment> kepstin, yeah that's the plan at the moment [18:18:38 CET] <kepstin> so you'd run ...\ffmpeg-10\ffmpeg.exe to do a 10bit encode, and ...\ffmpeg-8\ffmpeg.exe to do 8bit encode [18:18:45 CET] <alexpigment> right [18:18:45 CET] <kepstin> easy enough [18:18:53 CET] <alexpigment> i think i'm missing something [18:18:56 CET] <alexpigment> because that's the plan [18:19:09 CET] <alexpigment> are you implying that i could do something to save redundancy? [18:19:25 CET] <kepstin> alright, I'm just confused because you were talking about trying to figure out whether ffmpeg supported 10bit h264 or not [18:19:58 CET] <alexpigment> kepstin: the point was that i was hoping to trigger off of a command line entry whether to use ffmpeg 10-bit for x265 or to use 8-bit [18:20:19 CET] <alexpigment> in which case, i was hoping to just trigger off of a defined pix_fmt which only works with one or the other [18:20:24 CET] <kepstin> alexpigment: ah, and there's no real way to do that without both implementing an ffmpeg command line parse and knowing info about the input file [18:20:33 CET] <alexpigment> i already have logic to parse that command line, so it's pretty simple [18:20:46 CET] <alexpigment> the input file is an RBGA pipe [18:20:51 CET] <alexpigment> there is no transcoding being done here [18:21:03 CET] <alexpigment> anyway, that's not terribly important though [18:21:08 CET] <alexpigment> i think i've got all i need now [18:21:24 CET] <kepstin> but in this case, you're writing an ffmpeg command line saying to use 10bit or 8bit, then reading it and trying to figure out whether you told it to use 10bit or 8bit [18:21:45 CET] <kepstin> which seems a bit silly, just remember whether you wanted 10bit or 8bit in the first place :) [18:22:11 CET] <alexpigment> the presets will be just FFMPEG command lines. adding a bit depth is simple, probably, but requires a new check that doesn't currently exist [18:22:39 CET] <alexpigment> anyway, keptstin, i appreciate your help here, but i think we're talking in circles [18:22:45 CET] <kepstin> i guess so [18:22:54 CET] <alexpigment> and i have all i need at the moment [18:27:01 CET] <kepstin> it's just that in a given ffmpeg command, you can't always tell whether it's gonna be a 10bit or 8bit encode based *only* on the command line - if you don't explicitly specify an output pix_fmt, then it'll determine which to used based on what the encoder supports. [18:27:34 CET] <kepstin> so the same command line will give you 8bit output with an 8bit x264, and 10bit output with a 10bit x264, with no errors etiher way [18:27:50 CET] <alexpigment> kepstin, yes, the pix_fmt will always be explicitly called in my cse [18:28:49 CET] <alexpigment> *case [18:29:02 CET] <kepstin> right. still would probably better to store which ffmpeg to use separately from the command line, but if you know there's always gonna be a "-pix_fmt yuv420p" in there somewhere, that would work. [18:29:18 CET] <alexpigment> right. that's the current thinking [18:29:24 CET] <alexpigment> it's always there, so it can be parsed [18:29:54 CET] <alexpigment> outside of that, i would have to create a new field/flag in the preset code to store something that isn't directly used by FFMPEG [18:30:19 CET] <kepstin> right, because it's not directly used by ffmpeg, it's a meta flag saying which ffmpeg to use :) [18:30:25 CET] <alexpigment> i'd rather not make things messy in the preset definitions just to do something that can be inferred by the code to use a particular ffmpeg variant [18:31:10 CET] <kepstin> alexpigment: fun thing, if you run "ffmpeg -h encoder=libx264" on your two ffmpegs, it'll print out a list of "Supported pixel formats" for the x264 library used [18:31:28 CET] <kepstin> which i think is actually what you were asking for in the first place [18:32:34 CET] <kepstin> so you should get "yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p nv12 nv16 nv21" with the 8bit one, and "yuv420p10le yuv422p10le yuv444p10le nv20le" with the 10bit one (for x264) [18:33:18 CET] <alexpigment> awesome [18:33:22 CET] <alexpigment> even better info [18:33:27 CET] <alexpigment> that was what i was hoping for originally [18:33:37 CET] <alexpigment> thank you very much for that [18:34:38 CET] <kepstin> x265 is a bit different, i'm not sure how yours is built, but a single x265 library can support multiple bit depths [18:34:53 CET] <alexpigment> kepstin, yeah, it "supports it" but fails [18:35:01 CET] <alexpigment> i think that's a problem with ffmpeg rather than x265 itself [18:36:22 CET] <alexpigment> fortunately, i'm really only interested in 6 total - 420, 422, and 444, 8 and 10 of each [18:36:46 CET] <kepstin> alexpigment: hard to say. it depends a lot on exactly how x265 was built; you need to do something special to get a single lib supporting all bit depths [18:37:10 CET] <kepstin> it can be built to have separate libraries for separate bit depths like x264, too [18:37:15 CET] <ember3> hi, is there a built-in way to extract per-frame motion, i.e. interpolated from motion vectors? I'd like to compute minima within a time interval. found extract_mvs.c but nothing exposed via in e.g. ffprobe yet [18:37:58 CET] <alexpigment> yeah i heard yesterday that someone has a way to do it for x264 but it's just a patch at the moment. x265 (which is the only encoder i need 10-bit for) doesn't have a way as far as i understand to support multiple bit depths within ffmpeg [18:38:58 CET] <kepstin> alexpigment: hmm, works for me with x265 - on linux at least. my linux distro installs one with 8, 10, and 12 bit support :/ [18:40:07 CET] <kepstin> the same command thing, "ffmpeg -h encoder=libx265" should tell you what your particular lib supports with each ffmpeg version [18:41:09 CET] <kepstin> I get "yuv420p yuv422p yuv444p gbrp yuv420p10le yuv422p10le yuv444p10le gbrp10le yuv420p12le yuv422p12le yuv444p12le gbrp12le gray" on my box with the multi-bit-depth support, and "yuv420p yuv422p yuv444p gbrp" on a different one where it can only do 8bit. [18:41:58 CET] <kepstin> (I assume one built with 10bit support only would look like "yuv420p10le yuv422p10le yuv444p10le gbrp10le") [18:42:26 CET] <alexpigment> kepstin: yeah, if you try to do yuv420p on the high bit depth one, it'll fail i believe [18:42:31 CET] <alexpigment> at least in my tests [21:40:21 CET] <SpeakerToMeat> Greetings. [21:41:14 CET] <SpeakerToMeat> Question, when outputing a video to DPX codec, is there any way to set the bith depth of the dpx? can't find it [21:42:15 CET] <JEEB> you feed it a specific format of video it supports [21:42:38 CET] <JEEB> if you are talking of ffmpeg.c the simplest way might be to utilize -pix_fmt CORRECT_IDENTIFIER after the input [21:43:02 CET] <JEEB> CORRECT_IDENTIFIER being one of the things listed in ffmpeg -pix_fmts [21:43:15 CET] <SpeakerToMeat> So other than recoding the source video to another video format, and then recoding it to dpx, there's no way... [21:43:24 CET] <JEEB> uhh [21:43:27 CET] <JEEB> there's no recoding [21:43:39 CET] <JEEB> input => pixel format conversion => output [21:44:12 CET] <JEEB> input I should have probably noted as decoding and output as encoding [21:44:37 CET] <JEEB> it's not like it's the *encoder* 's job to suddenly do the pixel format conversion [21:44:51 CET] <JEEB> an encoder's job is to take an input and encode that image [21:44:57 CET] <JEEB> or audio sample, or whatever [21:45:30 CET] <SpeakerToMeat> JEEB: Then why am I getting 16 bith DPX from yuv422p10le ? [21:45:50 CET] <JEEB> SpeakerToMeat: pardon? [21:46:31 CET] <SpeakerToMeat> JEEB: Why when inputing yuv422p10le prores video and outputing DPX do I get 16 bit depth DPX instead of 10 bit (or 12 bit linear) [21:46:32 CET] <JEEB> if it's easier to note by linking your full command line and terminal output in a pastebin-like site and linking it here, please do that [21:46:52 CET] <SpeakerToMeat> Should I use a pastebin for a single line? [21:47:10 CET] <JEEB> the terminal output is that short? [21:47:43 CET] <JEEB> anyways, sounds like automagic conversion routine somewhere decides that is the best route :P [21:48:07 CET] <JEEB> because you're not specifying the output format [21:48:45 CET] <JEEB> AV_PIX_FMT_GBRP10BE and AV_PIX_FMT_GBRP10LE are supported by dpxenc [21:49:00 CET] <JEEB> that said if you're converting from YCbCr to RGB that already kind of drops the input bit depth [21:49:05 CET] <JEEB> because you're doing a big enough change [21:54:02 CET] <SpeakerToMeat> JEEB: There you go http://pastebin.com/EMZ7WBue [21:55:17 CET] <SpeakerToMeat> So I can't set the format if I'm moving from YCbCr to RGB? how do I find the formats dpxenc supports? and how is it specified on the command line? I'm missing it on --help, seriously :( [21:55:51 CET] <JEEB> you can set the format just fine [21:56:02 CET] <JEEB> it's what the automagic thing will try to convert the result [21:56:36 CET] <JEEB> how to find the supported pixel formats I'm not sure since I've always just peeked at the source, but the list is properly defined for each encoder and decoder so in theory it should be possible to show them [21:57:19 CET] <JEEB> ok, it's `ffmpeg -h encoder=dpx` [21:57:21 CET] <JEEB> most likely [21:57:34 CET] <JEEB> I just tested it with my encoder (utvideo) [21:57:41 CET] <JEEB> and shows a list of pix_fmts that it takes in [21:57:50 CET] <SpeakerToMeat> Ok I guess the formats are listed with pix_fmts? Yet it doesn't specify which dec/enc supports each of course [21:57:59 CET] <SpeakerToMeat> thanks I'll check that [21:58:16 CET] <SpeakerToMeat> JEEB: Yes, that lists the formats. thank you [22:03:57 CET] <SpeakerToMeat> JEEB: Now do I read you right and if I specify the pixel format for out it'll be overriden by auto? [22:08:33 CET] <SpeakerToMeat> Second question, if I have video at x*y input, can I output video at x*z (z > y) where the original image is left unscaled, but composited by layers onto a black background with an East (in imagemagick parlance, that is, vertically centered) centering? [22:08:59 CET] <SpeakerToMeat> Let me google "add letterbox" that might give me a result [22:09:09 CET] <furq> !filter pad [22:09:09 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#pad-1 [22:09:37 CET] <SpeakerToMeat> thanks [22:10:23 CET] <furq> you can use height=(1080-in_h)/2 if you only want to care about the output height [22:10:54 CET] <furq> wait nvm ignore that [22:11:19 CET] <furq> you can use x=(1080-in_h)/2 [22:25:32 CET] <SpeakerToMeat> furq: Or I can just put the numbers by hand, since I know the right numbers :) [22:25:41 CET] <SpeakerToMeat> Of course I have to account for indexing from 0... [22:26:28 CET] <Darby_Crash> hi guys i can't compile ffmpeg, configure run ok but make fail with this errors: https://clbin.com/1GWUg [22:28:30 CET] <Darby_Crash> this is the config.log https://clbin.com/2G01m [23:07:45 CET] <SpeakerToMeat> furq: perfect. thank you [00:00:00 CET] --- Sat Mar 4 2017

1 0

ffmpeg-devel.log.20170302
by burek 03 Mar '17

03 Mar '17

[00:09:42 CET] <atomnuker> smarter_: are golomb codes used in HEVC (and if yes, why?) [00:19:56 CET] <jkqxz> atomnuker: Yes, in the headers. Because doing full entropy coding of headers is a terrible idea (it saves pretty much nothing, and makes every operation which doesn't want to decode the whole bitstream hugely more annoying to do - compare VP8). [00:20:24 CET] <atomnuker> no, its a great idea [00:21:19 CET] <nevcairiel> doing entropy coding for headers would be insane on simple bitstream parsers and whatnot [00:21:20 CET] <atomnuker> in both situations you have to read everything before since you don't know how long they are [00:21:35 CET] <nevcairiel> its just a complexity we can do without [00:21:40 CET] <atomnuker> so in both situations you init a bitstream reader and you read [00:21:45 CET] <atomnuker> where's the problem? [00:22:05 CET] <nevcairiel> the problem is that I know how to implement golomb and other simple vlc codes, but i have no clue how to do cabac =P [00:22:29 CET] <atomnuker> easily solved, check the specs lol [00:22:41 CET] <nevcairiel> what exactly would you gain? [00:22:46 CET] <nevcairiel> other then some crazy sense of crazyness [00:22:46 CET] <atomnuker> (which you have to do anyway because there are a million and one ways to encode golomb) [00:23:05 CET] <atomnuker> uniformity, simplicity and encoding gains [00:23:07 CET] <jkqxz> The entropy coding is useless unless you have some more information about what the frequencies are going to be, so you are going to have to add dependency on some previous headers in order to exploit the redundancy. Suddenly you have no idea what a packet is without decoding all previous packets first. [00:23:18 CET] <atomnuker> you still do [00:23:33 CET] <atomnuker> opus does it [00:23:54 CET] <atomnuker> flat probabilities on all flags in the header-like section [00:24:46 CET] <nevcairiel> simplicity? by using cabac more? [00:24:49 CET] <nevcairiel> please [00:24:50 CET] <nevcairiel> :) [00:24:54 CET] <atomnuker> no no no, you don't get it [00:25:00 CET] <atomnuker> its _not_ adaptive [00:25:16 CET] <atomnuker> cabac can be just bac [00:25:22 CET] <atomnuker> no context adaptive stuff [00:25:32 CET] <jkqxz> So it's just a slightly different packing method for the headers which saves a few bits at the cost of additional complexity? Ok, I can live with that. [00:25:43 CET] <atomnuker> yes, exactly [00:25:54 CET] <nevcairiel> its video, headers are so small compared to the actual data that its not worth it [00:26:02 CET] <atomnuker> and you don't waste bits padding when switching between cabac and bac [00:26:03 CET] <jkqxz> Few bits is not enough to merit the complexity, yeah. [00:26:33 CET] <atomnuker> it doesn't add complexity, its just as complex or even less complex than golomb [00:26:48 CET] <nevcairiel> not every header field is g olomb [00:26:54 CET] <nevcairiel> there is plenty fixed size bit fields [00:27:03 CET] <atomnuker> they suck and shouldn't exist in packets [00:28:16 CET] <atomnuker> I just didn't realize hevc had a design old enough not to do that [00:28:17 CET] <jkqxz> The parameter sets are deliberately only fixed-width fields for the first few bytes so that very stupid devices can extract things like the profile information without even needing golomb decoding. [00:28:45 CET] <atomnuker> daala, opus, av1, they all have a monolithic bistream you need a reader to read through [00:28:58 CET] <jkqxz> In some sense, this is a huge waste. In another, who cares about the few bits there. [00:29:21 CET] <jkqxz> There are a lot of bits in the headers which you could infer or could be reduced by moving somewhere else, but it increases the complexity enough that it's not merited. [00:29:23 CET] <atomnuker> depending on the framerate it can be very significant [00:29:35 CET] <atomnuker> and bitrate [00:29:45 CET] <nevcairiel> i question that statement [00:29:49 CET] <nevcairiel> "very significant" [00:29:56 CET] <nevcairiel> on what, 90s modem rates? [00:29:58 CET] <atomnuker> opus with 2.5 ms packets at 40kbps [00:30:11 CET] <TD-Linux> strictly speaking av1 has the uncompressed header too (bitpacked) but yes that's still better than two entropy coders [00:30:12 CET] <nevcairiel> again, this is video [00:30:12 CET] <atomnuker> most of that will be header data [00:30:14 CET] <jkqxz> Sure, those people tho encode H.265 QCIF to send over an ISDN BRI. [00:30:15 CET] <nevcairiel> it never gets that low [00:30:51 CET] <nevcairiel> and in such a case maybe you should design a header-skipping feature or something [00:30:51 CET] <atomnuker> TD-Linux: yes but its constant and it fits in X bytes exactly, not like you have to pad [00:30:56 CET] <nevcairiel> group frames into GOPs with only one header [00:31:10 CET] <TD-Linux> when videoconferencing, many frames are nearly all skip and the header does add up to a lot (especially the vp9 compressed header if present) [00:31:46 CET] <jkqxz> Videoconferencing also has packet loss, which makes any sort of implicit data a disaster. [00:32:23 CET] <nevcairiel> the all-skip frames are still tiny though [00:32:35 CET] <nevcairiel> so even if a large precentage of them is header, its overall size is still low [00:33:01 CET] <jkqxz> The packet overhead is more important at that point. [00:33:45 CET] <jkqxz> You have to send one packet per frame, and that's already a hundred bytes or more of link-bandwidth used. [00:33:51 CET] <atomnuker> still, why would you not want the entire packet to not be entropy coded? the outer layer usually carries enough shit to tell you everything [00:33:54 CET] <atomnuker> e.g. RTP [00:34:16 CET] <nevcairiel> or it tells you nothing, eg. mpegts [00:34:42 CET] <TD-Linux> there are a few flags that you might want to be easily readable, like reference picture information, that could go into bitpacked [00:34:51 CET] <TD-Linux> golomb is kinda the sad middle ground though [00:35:35 CET] <atomnuker> yes, you have to pad to start an entropy coded bitstream, its usually more complex and slower to read and you still don't know where to start reading [00:37:01 CET] <atomnuker> or you can avoid padding and instead convert the bits won into more complexity and swear words into your code, as well as hate for the person who designed it [00:37:37 CET] <nevcairiel> but i dont want to have to swear when i write code [00:37:48 CET] <nevcairiel> so i prefer easy headers! [00:37:49 CET] <nevcairiel> :) [00:38:32 CET] <atomnuker> there you go, you put an *aligned* constant byte header in with the most minimal of information and you entropy code the rest [00:39:23 CET] <atomnuker> and then when someone wants to code additional parameters because their proprietary HDR needs them and they want that in the uncompressed header you unload on them instead [00:39:23 CET] <nevcairiel> whats wrong with a few single bits of padding anyway, 1 to 7 bits arent going to hurt you in a large video stream [00:39:38 CET] <atomnuker> no, that's okay, I was thinking something like 20 ood bytes [00:39:58 CET] <nevcairiel> what kind of weird alignment does your weird entropy coder need [00:40:22 CET] <nevcairiel> i have only seen byte-aligned borders in things [00:40:33 CET] <atomnuker> that's what I'm talking about [03:14:01 CET] <cone-670> ffmpeg 03Michael Niedermayer 07master:3250d4b39ccf: avformat/oggdec: remove unused parameter of ogg_restore() [03:14:01 CET] <cone-670> ffmpeg 03Michael Niedermayer 07master:fb6fa48fce3a: avformat/oggdec: Factor free_stream out [03:14:01 CET] <cone-670> ffmpeg 03Michael Niedermayer 07master:e46ab997506e: avformat/oggdec: fix leak in ogg_restore() [03:29:09 CET] <cone-670> ffmpeg 03Michael Niedermayer 07master:04c99c8042c8: avcodec/h264idct_template: Fix several runtime error: signed integer overflow [03:29:10 CET] <cone-670> ffmpeg 03Michael Niedermayer 07master:12c3e120fe8f: avcodec/ituh263dec: Use 0xffff as error code in h263p_decode_umotion() [03:29:11 CET] <cone-670> ffmpeg 03Michael Niedermayer 07master:f8060ab927f8: avcodec/wavpack: Check value before shift in wp_exp2() [03:29:12 CET] <cone-670> ffmpeg 03Michael Niedermayer 07master:4bed06637729: avcodec/vp56: Clear dimensions in case of failure in the middle of a resolution change [03:49:30 CET] <svanheulen> :q [09:23:30 CET] <wm4> mateo`: you wrote the lavc mediacodec code, right? does it have no support for GPU video frames? [09:24:19 CET] <mateo`> if by GPU video format you mean output to a surface, it does support it [09:24:30 CET] <wm4> I mean I only see this terrible releaseOutputBuffer thing, which an idiot must have designed [09:24:34 CET] <wm4> https://developer.android.com/reference/android/media/MediaCodec.html#relea… [09:24:47 CET] <wm4> this is pretty much directly exposed by lavc [09:24:59 CET] <wm4> it appears once the surface is rendered, you can't do it again (????) [09:25:14 CET] <mateo`> nope you can't ... [09:25:26 CET] <wm4> also this whole thing is hilariously deadlock-prone, citing another part of the docs: " Specifically, it is possible that a codec may hold off on generating output buffers until all outstanding buffers have been released/resubmitted. " [09:25:33 CET] <wm4> and this api is NEW? [09:25:55 CET] <wm4> dxva2 was better a decade ago [09:26:15 CET] <wbs> I guess it is deliberatly very abstract to make it work with wildly different socs [09:26:21 CET] <mateo`> and yes, you need to release the output buffers as fast as possible [09:26:35 CET] <wm4> wbs: so I guess we have to rely on windows phone and iOS to raise the standards [09:26:48 CET] <wm4> while android is the lowest common denominator of stupid [09:27:14 CET] <wbs> wm4: on iOS you can't get a gpu frame either iirc, but you can get the data in a gl compatible format [09:28:02 CET] <wm4> wbs: well on iOS you have CVPixelBufferRefs, which works just like on OSX [09:28:11 CET] <wm4> (with some unnecessary difference with GLES vs. GL) [09:28:19 CET] <mateo`> wm4: and depending on the resolution / profile of the stream you decode, the decoder can lock if you retain 1 or 2 buffers ... [09:28:31 CET] <wbs> wm4: yeah [09:29:30 CET] <wm4> so while it's probably "ok" that it provides sub-par mechanisms for retarded SoCs, does it not provide better mechanisms for capable hardware? [09:30:10 CET] <mateo`> wm4: in the application i work for, i render as fast as possible to a GL_TEXTURE_EXTERNAL_OES [09:30:57 CET] <mateo`> and copy to a GL_TEXTURE_2D if I need to do more things with it [09:31:44 CET] <wm4> I bet that involves forced RGB conversion too [09:32:39 CET] <cone-920> ffmpeg 03Carl Eugen Hoyos 07master:3733039610d7: lavf/flacdec: Return maximum score if the streaminfo header is valid. [09:33:09 CET] <mateo`> not to mention that you need a java listener implementation if you want to copy the surface to the GL_TEXTURE_EXTERNAL_OES, requiring your final app to ship the listener class, and your jni code to use it [09:33:25 CET] <wm4> fucking terrible [09:33:38 CET] <wm4> fuck google etc. [09:33:41 CET] <mateo`> +1 [09:34:12 CET] <wm4> it gets even worse if you want to do transcoding [09:35:03 CET] <JEEB> now guess why people added neon to x264. hue [09:35:08 CET] <mateo`> the encoding part is pretty easy if you stay in the java world [09:35:25 CET] <mateo`> but the quality the encoders output is horrible [09:35:38 CET] <JEEB> yup [09:35:48 CET] <wm4> apparently you can only setup decoder->encoder (no control over filtering or even what frames are encoded), unless you copy back to normal RAM [09:36:35 CET] <mateo`> I have to bump the bitrate to 40mbps to have something ok-ish with complex video footage [09:37:17 CET] <mateo`> if you want to control i guess you will want to stay in the gl world [09:37:30 CET] <mateo`> you get the output to a texture, you filter, you render back to the encoder surface [09:40:32 CET] <mateo`> JEEB: if there is no licensing issue, i would be tempted to include x264 in the app ... at least the users would have something they can watch in the end [09:56:28 CET] <wm4> michaelni: new filter-merge patches on the ML, I'll push in 24h [09:56:39 CET] <wm4> michaelni: unless you approve earlier [09:57:12 CET] <nevcairiel> did you fix all the things now? [09:57:34 CET] <wm4> who knows [09:58:06 CET] <wm4> it's all corner-caseish shit about which nobody knows whether it should or shouldn't work [09:58:49 CET] <nevcairiel> at least using the input timebase seems to reduce the rounding error issues [09:59:02 CET] <wm4> yes, some [10:32:39 CET] <cone-920> ffmpeg 03wm4 07master:554bc4eea8aa: avcodec, avutil, avformat: remove AVOption requirement for some fields [10:32:40 CET] <cone-920> ffmpeg 03wm4 07master:227f6e1e8d4b: avformat: fix AVStream private fields marker [10:32:41 CET] <cone-920> ffmpeg 03wm4 07master:ade7c1a2326e: avcodec/videotoolbox: allow not setting the kCVPixelBufferPixelFormatTypeKey [10:32:42 CET] <cone-920> ffmpeg 03wm4 07master:f07492e7fb66: avcodec/videotoolbox: set kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey [11:16:27 CET] <wm4> jkqxz: which is your patch that fixes the vaapi frame pool assertion failures I like to hit so often? I'll push it [11:18:18 CET] <jkqxz> wm4: <https://git.libav.org/?p=libav.git;a=commit;h=d30719e62de68975cbc7ffd318df0…> [11:18:49 CET] <jkqxz> (Sorry, I should have done that when you last pointed it out.) [11:21:09 CET] <cone-920> ffmpeg 03Mark Thompson 07master:2b8151c80690: hwcontext_vaapi: Don't abort on failing to allocate from a fixed-size pool [11:21:13 CET] <wm4> thanks [11:23:58 CET] <BtbN> I wonder what the hell VLC is doing on this laptop. It can't even play a 720p60 stream without over-using the CPU so badly that it lags the entire system. [11:24:52 CET] <BtbN> MPC-HC plays the same stream with like 30% CPU usage. Which is still surprisingly high for something that should be handled by hwaccel. [11:25:09 CET] <BtbN> And MS Edge plays it without any noticable CPU usage. [11:25:15 CET] <wm4> and mpv? [11:25:17 CET] <nevcairiel> did you turn hwaccel on then? :) [11:25:26 CET] <BtbN> In VLC it's set to automatic [11:25:33 CET] <BtbN> In MPC-HC it is using it [11:25:45 CET] <wm4> with vlc I can never tell how to enable hwaccel, and even worse, how to tell whether it's using it [11:26:02 CET] <BtbN> I guess I could look at a debug log to determine it [11:26:08 CET] <BtbN> MPC-HC has a H/W indicator [11:26:16 CET] <ubitux> last time i tried i could tell, it was all green [11:26:26 CET] <BtbN> And I don't have mpv on Windows [11:26:27 CET] <ubitux> (but that was long time ago) [11:27:44 CET] <nevcairiel> h264 i guess? [11:27:49 CET] <BtbN> yeah, a Twitch stream [11:28:01 CET] <BtbN> so HLS with h264 and aac [11:31:01 CET] <wm4> BtbN: can you download and try mpv? just curious what it'll say [11:31:20 CET] <wm4> though I'd expect some kind of failure [11:31:25 CET] <BtbN> I guess it supports DXVA/D3DVA? [11:31:29 CET] <wm4> yes [11:36:41 CET] <BtbN> wm4, any recommended build for Windows? There seem to be several people offering builds [11:37:26 CET] <wm4> probably best to use https://mpv.srsfckn.biz/ [11:40:07 CET] <cone-920> ffmpeg 03Kostya Shishkov 07master:a63496cc8824: avcodec: add ClearVideo decoder [11:42:37 CET] <BtbN> that one outperforms even edge [11:42:45 CET] <BtbN> And I didn't specify any parameters except for the HLS url [11:44:08 CET] <BtbN> No idea if it's using hwaccel, but with only 4% CPU usage I'd be surprised if not. This Laptop has a 2.2GHz dual core... [14:24:40 CET] <wm4> michaelni: just as expected [14:24:43 CET] <wm4> michaelni: fuck you too [14:33:13 CET] <kierank> wm4: ? [14:34:25 CET] <wm4> same shit again [14:35:19 CET] <wm4> just when I post the patches, he comes up with the same undebuggable failures again (like the valgrind issue with "private" samples), makes me hunt down samples, comes up with bullshut corner cases [14:35:41 CET] <wm4> nothing over the past 1 or 2 weeks where he had time to mention any failures to me [14:36:09 CET] <durandal_170> but he likes to solely work on security patches [14:36:26 CET] <wm4> then why does he care about filter changes [14:39:30 CET] <BBB> michaelni: share the full sample collection and failure log please [14:39:34 CET] <BBB> michaelni: this is ridiculous [14:53:07 CET] <wm4> so the failure is because of sub2video, again [15:06:25 CET] <BBB> wm4: btw, the fix michaelni uses for The first time you mentioned this. Why didn't you do so a week ago? When I complained that you come up with a new case punctually at exactly the time when I want to merge the patches. is to simply push the patch after amending the comments of the first review round [15:06:35 CET] <BBB> wm4: you could do that too if you wanted to circumvent it [15:09:21 CET] <wm4> BBB: so I should use underhanded methods of bullshit to work around our broken development model? [15:09:41 CET] <wm4> doesn't sound too great to me [15:10:34 CET] <BBB> Im not saying what you should or should not do, Im just mentioning existing accepted development methods [15:11:05 CET] <BBB> (in line with your reasoning in doc: clarify development rules) [15:11:37 CET] <BBB> it is up to you to decide what to do or not do [15:14:51 CET] <Compn> some samples are available under nda only... [15:19:11 CET] <Compn> you are upset that a patch review comes at an inopportune time for you. but instead you should be happy that someone took the time to test it out on a lot more samples. [15:19:25 CET] <Compn> e.g. did you test your filter with all of samples.ffmpeg repo? [15:19:35 CET] <Compn> i am guessing not. [15:20:34 CET] <Compn> you could ask if its a blocker, i doubt crashes without samples is a blocker [15:20:40 CET] <durandal_170> Compn: keep calm [15:20:48 CET] <Compn> wm4: but imo this is not something to be insulted by. [15:21:16 CET] <Compn> durandal_170 : how'd you figure out clearvideo without the encoder ? [15:21:43 CET] <Compn> durandal_1707 : how'd you figure out clearvideo without the encoder ? [15:22:19 CET] <durandal_1707> dunno [15:26:04 CET] <Compn> durandal_1707 : what should i use to generate pure white frame? do you have quick ffmpeg line for it? so when i finally get a windows 95 virtual machine running i can put it into vivo encoder... [15:30:55 CET] <durandal_1707> Compn: ffmpeg -f lavfi -i color=white output [15:31:50 CET] <wm4> Compn: I'm just going to tell you that I'll pretend I'm ignoring what you wrote [15:33:10 CET] <Compn> wm4 : you've broken the code of conduct by saying "fuck you" to michael btw [15:34:03 CET] <wm4> Compn: michaelni did too... the CoC says "Be considerate." [15:34:36 CET] <Compn> i dont remember any malice in the patch review... was there some other mail or message you are talking about ? [15:36:03 CET] <Compn> BBB , kierank : why are you encouraging this ? [15:36:27 CET] <wm4> why are _you_ encouraging this [15:36:45 CET] <BBB> Compn: I dont think Im encouraging anything out of the ordinary [15:36:49 CET] <kierank> wm4: ignore compn [15:36:58 CET] <BBB> Compn: Im indicating existing development practices [15:37:15 CET] <BBB> Compn: I also agree that nda samples are great for testing but cannot be used to block patches, which even you seem to agree with [15:37:25 CET] <durandal_1707> Compn: michaelni said similar by keeping samples of useless content [15:37:29 CET] <Compn> im not talking about the patch, only wm4's reactions... [15:37:37 CET] <BBB> Compn: if google or who-ever supplied the sample thinks the sample is important for regression testing, then the sample should be made publicly accessible for all developers [15:38:16 CET] <durandal_1707> Compn: i would react exactly same as wm4 did [15:38:19 CET] <Compn> BBB : what about wm4's violation of the CoC ? [15:38:23 CET] <BBB> Compn: as for wm4s reaction, I totally understand that if youve spent weeks on a particular tedious feature that you would really like to get into the main tree, it sucks if its repeatedly kicked down the lane [15:38:36 CET] <Compn> thats not a reason to break the coc. [15:38:38 CET] <BBB> Compn: I agree that fuck you isnt appropriate [15:38:43 CET] <Compn> thank you [15:38:46 CET] <wm4> Compn: your CoC argument is bullshit that only detracts from the real issue (which on the other hand you seem not to understand) [15:38:55 CET] <BBB> wm4: please dont say fuck you, although I understand your frustration [15:39:14 CET] <Compn> dont blame me, i voted against CoC ... [15:39:30 CET] <wm4> it's not a substantial "insult", especially because I said "fuck you too" not "fuck you" [15:39:42 CET] <wm4> (why are we arguing about this... I guess the CoC works) [15:39:46 CET] <BBB> :) [15:39:56 CET] <BBB> soooo lets get back on-topic [15:40:33 CET] <Compn> "thank you for patch review, i cant fix the bugs without samples, so i' [15:40:45 CET] <Compn> "thank you for patch review, i cant fix the bugs without samples, so i'd like to push this now and fix later when samples appear, ok?" [15:40:56 CET] <Compn> fair enough ? [15:41:01 CET] <Compn> im just trying to help [15:41:21 CET] <Compn> its easy to type that sentence in a mail (or just copy and paste) [15:43:51 CET] <BBB> Compn: I think your question why are you encouraging this was directed at me not immediately telling him to not say fuck you (too), right? I think the honest answer is that Im sort of just ignoring those type of comments and instead I just focus on the substance of the issue& whether thats a good thing or not remains to be determined .. [15:44:33 CET] <Compn> BBB : encouraging some devels to be angry at other devels for a patch review is not helping anything or anyone [15:44:52 CET] <BBB> I agree [15:45:36 CET] <BBB> but Im pretty sure that if we go past form into substance, we all more-or-less agree on the technical issues at hand here, right? [15:45:53 CET] <BBB> even you appear to generally agree that non-public samples cannot be used to block a patch [15:46:15 CET] <BBB> (maybe minus security/crashes, etc., maybe with nice wording, etc. modulo div) [15:46:38 CET] <Compn> i guess i cant remember the other thing i thought you were encouraging so i'll drop it [15:46:48 CET] <Compn> sorry. [15:46:56 CET] <BBB> I suggested he push the patch after addressing the concerns, maybe that? [15:47:04 CET] <Compn> yes, kinda [15:47:18 CET] <Compn> thats maybe not the 100% best suggestion [15:47:38 CET] <BBB> its not great, but some people already do it, so if he wants to get the patch off his back, he could consider it [15:47:47 CET] <BBB> I probably wouldnt want to exactly encourage it [15:47:57 CET] <BBB> but I wouldnt be fundamentally opposed to it either [15:48:12 CET] <Compn> like i said, i agree with you BBB [15:48:15 CET] <BBB> maybe I wouldve considered it for the msvc patch [15:48:26 CET] <BBB> speaking of shitty patches I totally wanted to get off my hard disk ;) [15:48:34 CET] <Compn> posting one sentence asking if michaels' crashes are a blocker , otherwise push is fine too... [15:48:39 CET] <Compn> :) [15:48:53 CET] <BBB> I guess we agree mostly on substance then, so good :) [15:48:57 CET] <ismail> Compn: btw. can you copy the sample from https://trac.ffmpeg.org/ticket/5998#comment:13 ? [15:49:01 CET] <Compn> just trying to encourage people to communicate and not be insultee [15:49:02 CET] <Compn> d [15:49:09 CET] <BBB> yeah [15:49:23 CET] <Compn> theres no reason to be insulted [15:49:39 CET] <Compn> you may feel insutled , personally, but i dont think michaelni meant to [15:49:45 CET] <Compn> i'm not sure if there is a word for this [15:49:48 CET] <Compn> intent maybe [15:49:51 CET] <Compn> no malice intended [15:50:35 CET] <Compn> ismail : downloading [15:50:44 CET] <ismail> Compn: thanks! [15:52:26 CET] <Compn> hmm i forgot where they go on ffmpeg box [15:52:35 CET] <ismail> bah :) [15:52:38 CET] <Compn> where in samples is trac files ? [15:52:49 CET] <Compn> samples.ffmpeg.org/???/profit [15:53:22 CET] <Compn> ah i was in the right spot [15:54:24 CET] <Compn> ismail : should be here in 30 mins http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket5998/ [15:54:29 CET] Action: Compn afk [15:55:49 CET] <ismail> nice, thanks. [16:02:03 CET] <jamrial> michaelni: why is the ffv1 encoder even creating v2 streams if the draft spec specifically mentions such files shouldn't exist and doesn't cover them at all beyond that? [16:04:06 CET] <Compn> ismail : i forgot, can you post to that bug saying the sample is moved? [16:04:17 CET] <Compn> if you have trac account, otherwise i'll do it later [16:04:20 CET] <Compn> if someone reminds me [17:21:53 CET] <michaelni> jamrial, it shouldnt create them by default or without user explicitly overriding. being able to force their creation makes sense to test the decoder so any files out there continue to be supported in the future [17:22:12 CET] <michaelni> there may be other reasons that i fail to see as well [17:37:52 CET] <jamrial> michaelni: alright. just wondering since the spec is very clear about them not being valid files at all [17:41:13 CET] <michaelni> yes for IETF RFC, its simpler to keep a historic corner case that would complicate the spec and shouldnt exist in the wild out of the doc [17:52:33 CET] <svanheulen> I have a streaming video format with no timeing/framerate info. Each video frame is meant to be displayed immediately as it's received. I want to make a protocol/demuxer/decoder for it, any advice on how to handle something like that? [17:53:12 CET] <BtbN> that's not how audio/video works [17:53:36 CET] <BtbN> pretty sure ffmpeg will do horrible things without somewhat sensible timestamps [17:54:27 CET] <svanheulen> yeah, it's a pretty annoying format :/ [17:55:14 CET] <svanheulen> I was thinking maybe I could insert timestamps as I receive packets in the protocol... ? [17:56:35 CET] <jkqxz> I think some of the device things work like that. If you set a suitably fine time_base and then set pts on packets to the current time as they arrive then it basically works. [18:07:51 CET] <cone-920> ffmpeg 03Carl Eugen Hoyos 07master:d1bfd19ad196: doc: Link to "Resampler Options" in the aresample documentation. [18:13:33 CET] <cone-920> ffmpeg 03Carl Eugen Hoyos 07master:46082c2b3f21: lavc/sheervideo: Fix Y prediction for interlaced frames with transparency. [18:27:46 CET] <wm4> man I spent way too much time of my life to write this shitty email [18:35:39 CET] <atana> michaelni, ping [18:36:34 CET] <atana> michaelni, I tried running the script. it says "peakpoints_check.sh: 64: peakpoints_check.sh: Syntax error: Bad fd number" [18:37:26 CET] <atana> also in the log 'peakpoints2.log.insert' while printing fingerprint it report MatchInfo Array not allocated [18:37:39 CET] <atana> *reallocated [18:39:21 CET] <michaelni> atana, did you adjust the directory names ? the ones on the disc must match the script and should not contain any odd things like () [18:42:06 CET] <atana> when I extracted the dataset I got two directories 'genres' and 'mir*' I change 'mir*' to 'mir-10secsnippets' and set DIR=path-to-parent directory of genres [18:48:18 CET] <michaelni> atana, what exactly in the script fails ? [18:48:34 CET] <michaelni> line 64 is "lookupmultiple mir-10secsnippets/classical. 1 10" [18:48:43 CET] <michaelni> line 63 is "lookupmultiple mir-10secsnippets/blues. 10 10" [18:48:54 CET] <michaelni> why does 63 work but 64 not ? [18:49:17 CET] <atana> Don't know it just says 'bad fd number' [18:50:45 CET] <michaelni> atana, what does it say with "bash -x peakpoints_check.sh" ? [18:52:15 CET] <atana> seems to work now. I used sh instead of bash [18:52:51 CET] <michaelni> ok but the sccript says "#!/bin/bash" at its top [18:57:40 CET] <atana> 57 failures [18:58:11 CET] <michaelni> atana, great so we have a way to test it now [18:59:12 CET] <atana> also 'MatchInfo array not reallocated' in the insert log [18:59:42 CET] <adeeln_> durandal_1707: I've cleared the master branch, but now git log gives "fatal: bad default revision 'HEAD'" [18:59:54 CET] <atana> It should happen when enough memory is not present [19:00:16 CET] <michaelni> atana, the found=1 code checks for (count == 7) i dont think that makes sense, does it have fewer failures without that ? [19:00:19 CET] <durandal_1707> adeeln_: what says git reflog? [19:00:54 CET] <adeeln_> durandal_1707: same "fatal: bad default revision 'HEAD'" [19:01:19 CET] <durandal_1707> adeeln_: congrats on breaking git [19:01:49 CET] <adeeln_> :" what do I do? I created a backup btw [19:03:22 CET] <michaelni> atana, you check mi_size before its increased i think [19:04:46 CET] <atana> oh yes, that should be commented out [19:07:46 CET] <durandal_1707> adeeln_: try get ffmpeg compiling and running and git log working [19:14:12 CET] <atana> michaelni, what does variable songidpart and count refers to? [19:16:23 CET] <atana> oh that's id and count is total sample to consider(10 from each) [19:16:51 CET] <michaelni> yes, i used 10 as it would likely get a bit slow with more [19:18:09 CET] <atana> michaelni, the found=1 code checks for (count == 7) .... I didn't understand this [19:18:34 CET] <atana> is it in the script you are referring to? [19:18:57 CET] <wm4> michaelni: crash fixed, pushed a rebased patchset to my github filter-merge branch (latest commit is the fix for your sample) [19:19:50 CET] <atana> ok it's the peakpoint2 filter I will make it less and check the results [19:20:10 CET] <wm4> michaelni: feel free to test it until tomorrow, I'll then take a look, but I'll push it at 9 AM CET [19:21:46 CET] <Compn> wm4 : you know that michaelni said he would not be project leader ,not that he was leaving the project, right ? [19:22:05 CET] <Compn> although a lot of people took the email to mean the latter. [19:22:49 CET] <Compn> and it was even reported as such in some disreputable news sites [19:27:48 CET] <atana> michaelni, with count==4 -> 17 failures however it also print "peakpoints_check.sh: line 29: [: too many arguments" I used `bash peakpoints_check.sh | grep -c "/home*"` to get count [19:29:12 CET] <wm4> Compn: no I didn't [19:29:31 CET] <wm4> Compn: I guess not knowing The Truth makes those news sites "disreputable" [19:29:36 CET] <wm4> and myself too [19:30:33 CET] <michaelni> atana, i suggest to remove count==4 thats the loop counter if iam not mistaken [19:31:10 CET] <michaelni> match_count alone should be enogh [19:31:33 CET] <atana> with count==3 0 failures [19:33:12 CET] <michaelni> atana, does the sccript finish in this case? or does it fail with an error? [19:33:21 CET] <atana> michaelni, count==7 was checking if all 8 freq matched then it should go for matching time diff [19:34:43 CET] <atana> that's matching all 8 freq in a entry and then try to match timediff [19:36:36 CET] <atana> michaelni, script finishes in that case [19:36:41 CET] <adeeln_> durandal_1707: I've cloned a new repository, git log is working now. Can the old compile be used? [19:37:07 CET] <Compn> wm4 : i didnt mean to imply it like that [19:37:15 CET] <Compn> but some people heard about it from those sites which were wrong [19:38:28 CET] <michaelni> atana, can you push your version to github ? [19:38:58 CET] <durandal_1707> adeeln_: ? just use old patch, you cannot use old compile [19:39:07 CET] <atana> michaelni, with count==3? [19:39:18 CET] <durandal_1707> adeeln_: please develop in separate branch [19:40:06 CET] <adeeln_> durandal_1707: okay, I will go through the process as before, in a new branch this time. [19:40:13 CET] <michaelni> atana, the version that works with 0 failures [19:40:21 CET] <atana> yes pushed [19:40:30 CET] <atana> that's the one with count==3 [19:41:19 CET] <atana> which means it only checks 3 frequency matches in a entry and then if all timediff matches then a 'match found' [19:42:31 CET] <michaelni> atana, doesnt work i just get "./peakpoints_check.sh: line 29: [: too many arguments" [19:43:00 CET] <atana> also prints OK [19:43:26 CET] <atana> what does `bash peakpoints_check.sh | grep -c "/home*"` gives [19:44:23 CET] <michaelni> atana, the script is buggy [19:44:56 CET] <michaelni> atana, replace 'if [ $found != $expected ] ; then' by 'if [ "$found" != "$expected" ] ; then' [19:45:18 CET] <michaelni> that was my mistake [19:52:48 CET] <JEEB> hmm [19:53:06 CET] <JEEB> so the libvpx decoder has to be enabled for libvpx to be usable? [19:53:35 CET] <JEEB> I just happened to build libvpx without any decoders [20:06:28 CET] <jamrial> JEEB: try --enable-libvpx --disable-decoder=libvpx_vp8,libvpx_vp9 [20:08:15 CET] <atana> michaelni, why is it printing /home/atana/music/mir-10secsnippets/rock.00000-snippet-10-0.wav 900 [Parsed_peakpoints2_0 @ 0x41f2f00] Matched Song ID is -1 line? [20:08:43 CET] <JEEB> jamrial: trying [20:08:54 CET] <atana> isn't the script supposed to capture integer part from the line "Match Song..." [20:08:55 CET] <atana> ? [20:11:47 CET] <atana> also for count==7 `bash peakpoints_check.sh|grep -c "OK"` says 103 matches [20:12:36 CET] <michaelni> atana, i guess with count==3 it fails more fatally [20:12:39 CET] <JEEB> jamrial: lol I passed with also disabling the vp8 encoder, but then the result is "libvpx enabled but no supported decoders found" :DDD [20:13:08 CET] <michaelni> atana, what if you remove count==7 and remove the break; after "// this hash no a match, try next hash" [20:13:23 CET] <jamrial> that means the vp9 encoder was also disabled [20:14:01 CET] <atana> michaelni, is the current script ok ? as it gives 103 occurrence of "OK" max could be 100 [20:14:45 CET] <JEEB> jamrial: ok, feels like my pkg-config file is borked or something [20:14:45 CET] <michaelni> atana, there are 100 input files but more short recordings i guess that are looked uo [20:14:47 CET] <michaelni> uP [20:14:55 CET] <JEEB> <vpx/vpx_encoder.h> not found [20:14:57 CET] <jamrial> JEEB: check config.log, look for libvpx_vp9_encoder, see what it says about the checks [20:15:40 CET] <jamrial> that's not pkg-config then, but your libvpx build not installing that header [20:16:35 CET] <atana> michaelni, and printing the [Parsed_. ...] is it suppose to happen? which means found values is that whole string not integer [20:19:43 CET] <michaelni> atana, i guess that you refer to the case where the lookup fails to find anything [20:25:30 CET] <atana> 9 failures when removing count and commenting break [20:25:38 CET] <atana> michaelni, ^ [20:32:44 CET] <michaelni> atana, excellent [20:39:25 CET] <michaelni> atana, next try to adjust the value below // discard entries with less than 3 peak points [20:39:42 CET] <atana> ok [20:58:53 CET] <atana> michaelni, n>2 -> 8 failures, n > 3 -> 9 failure, n > 4 -> 14 failures, n > 5 -> 45 failures [20:59:39 CET] <michaelni> atana, n>2 is best then [21:00:09 CET] <atana> commenting it also gives 8 failures [21:00:58 CET] <atana> I will make it n > 2 then [21:01:07 CET] <michaelni> ok [21:02:03 CET] <atana> pushed [21:03:24 CET] <michaelni> atana, next thing to try is to apply a window function before the FFT like a Hamming window, this should be more correct and i hope improves the matches but has to be tested to see if it really improves things [21:05:12 CET] <michaelni> atana, see ff_generate_window_func() [21:05:25 CET] <atana> ok [21:45:33 CET] <BBB> what does this mean in yasm? [21:45:35 CET] <BBB> Undefined symbols for architecture x86_64: [21:45:36 CET] <BBB> "", referenced from: [21:45:51 CET] <BBB> ..(a)11820.branch_instr in filename.o [21:55:30 CET] <jamrial> BBB: never seen that before. did you make some changes to the x86inc magic, or try to abuse it in some weird way? [21:55:45 CET] <BBB> I found it by binary search %if 0 around code [21:55:56 CET] <BBB> I used [rsp*0*mmsize] instead of [rsp+0*mmsize] somewhere [21:56:13 CET] <BBB> apparently that becomes [] [21:56:20 CET] <BBB> (which is kinda duh, and kinda illogical) [21:56:28 CET] <BBB> but that causes the linking error [22:08:11 CET] <unholy_me> hello! [22:08:26 CET] <kierank> hello [22:08:44 CET] <unholy_me> XPM decoder implemented in libavcodec: This has to be implemented in:https://github.com/FFmpeg/FFmpeg/tree/master/libavcodec? [22:10:00 CET] <unholy_me> Any pointers on how to start? [22:11:36 CET] Action: unholy_me : New to ffmpeg [22:11:44 CET] <Compn> theres a demuxer/decoder example, i think xpm spec somewhere too, and xpm samples [22:12:03 CET] <Compn> what programming experience do you have, unholy_me ? [22:12:19 CET] <unholy_me> I am good in c [22:12:37 CET] <unholy_me> Coded quite a lot [22:13:21 CET] <Compn> i think there might be some other people also working on xpm . just letting you know, you may have competition for the same thing [22:13:25 CET] <Compn> or they might have dropped out [22:13:35 CET] <Compn> hard to tell, people dont communicate well these days [22:14:13 CET] <unholy_me> any suggestion which project to start on? [22:15:11 CET] <Compn> i am not sure :) [22:15:17 CET] <Compn> maybe ask durandal_1707 or michaelni [22:15:37 CET] <unholy_me> Cool! Thanks BTW [22:15:43 CET] <unholy_me> You a mentor? [22:16:22 CET] <durandal_1707> unholy_me: see other codecs and commits that add new decoders as example [22:16:53 CET] <JEEB> I think libav had a wiki article on adding a new decoder, not sure if FFmpeg has one [22:17:17 CET] <Compn> i am not [22:17:26 CET] <Compn> we had a demuxer howto [22:17:32 CET] <Compn> i am not seeing decoder howto [22:18:00 CET] <Compn> https://wiki.multimedia.cx/index.php/FFmpeg_codec_HOWTO [22:18:10 CET] <Compn> but probably using wrong / old api hehe [22:18:25 CET] <JEEB> that does look familiar [22:18:41 CET] <JEEB> but yeah, looking at some of the newer avcodec decoders should be helpful [22:21:26 CET] <unholy_me> @durandal_1707 any good,basic ones? [22:23:17 CET] <Compn> you mean a good basic decoder to look to as an example ? [22:23:44 CET] <durandal_1707> unholy_me: search fo xbm decoder in logs, xpm is going to be similar [22:25:50 CET] <unholy_me> XBM decoder? okay :) [23:05:20 CET] <unholy_me> i am up for the ambisonic project [23:06:00 CET] <unholy_me> Pointers on where to start? [23:07:48 CET] <durandal_170> unholy_me: write filter as in project wiki [23:08:17 CET] <durandal_170> just to do simple square decoder [23:08:48 CET] <unholy_me> can you give me the link? [23:09:03 CET] <durandal_170> look how are other filters are done [23:09:22 CET] <durandal_170> unholy_me: link to what? [23:10:08 CET] <unholy_me> where the other filters are done [23:10:28 CET] <durandal_170> it is in ffmpeg repo [23:10:49 CET] <durandal_170> have you done git clone? [23:10:55 CET] <unholy_me> yes [23:11:03 CET] <unholy_me> i have cloned it [23:11:36 CET] <durandal_170> see libavfilter/af_pan.c [23:11:45 CET] <unholy_me> yup i am on that [23:12:57 CET] <durandal_170> unholy_me: for square it would need 4 channels ambisonic input [23:13:24 CET] <durandal_170> and give 4 channels in output [23:13:52 CET] <unholy_me> ohkay... [23:14:12 CET] <durandal_170> read ambisonics info on wikipedia [23:15:57 CET] <unholy_me> why exactly would it require 4 channels? [23:16:34 CET] <durandal_170> unholy_me: ambisonics are usually 4 channels [23:17:40 CET] <durandal_170> there is ambisonic info and additional links on wikipedia [23:24:52 CET] <unholy_me> so w,x,y,z are the 4 channels? [23:25:03 CET] <durandal_170> yes [23:26:56 CET] <unholy_me> okay, so what exactly is FFmpeg/libavfilter/af_pan.c doing? [23:27:16 CET] <unholy_me> last part is the struct, which is initializing variables [23:27:24 CET] <unholy_me> i got that [23:28:12 CET] <durandal_170> panning [23:28:30 CET] <durandal_170> see doc/filters.texi [23:30:05 CET] <unholy_me> okay [23:37:59 CET] <unholy_me> okay i read filters.texi a little bit [23:38:29 CET] <unholy_me> understood about how signal is splitting [23:43:55 CET] <unholy_me> went through the code for af_pan [23:44:49 CET] <unholy_me> what is the function cofig props doing? [23:46:15 CET] <durandal_170> its setting input and output channel layouts and samplerate and sampleformat [23:50:12 CET] <unholy_me> let me see if i get this right [23:51:03 CET] <unholy_me> parse channel name is just removing spaces and then *gets channel layout*? [23:52:32 CET] <unholy_me> okay [23:52:43 CET] <unholy_me> what is init() doing [23:52:44 CET] <unholy_me> ? [23:53:21 CET] <unholy_me> I think it just rejects wrongly named channels [23:53:24 CET] <unholy_me> am i right? [00:00:00 CET] --- Fri Mar 3 2017

1 0

ffmpeg.log.20170302
by burek 03 Mar '17

03 Mar '17

[00:01:14 CET] <llogan> -crf and -b:v are mutually exclusive. use only one. probably a 98% chance you should use -crf instead of -b:v. [00:06:35 CET] <chandoo> what is this mean "Invalid UE golomb code" [00:07:38 CET] <chandoo> i have lot of this errors as well "[NULL @ 04dc7ba0] RTP: missed 128 packets" [00:09:22 CET] <RossW> Thanks for that... I started with an early ffmpeg which didn't use crf and I had to fiddle bitrate, so that was legacy... [00:09:54 CET] <RossW> and about to get back to the code, telephone interruptions here, and it really kills my train of thought :( [00:13:08 CET] <chandoo> [Parsed_overlay_11 @ 061d4480] [framesync @ 059cb368] Buffer queue overflow, dropping. [00:13:25 CET] <chandoo> i have lot of these errors while getting rtsp feed from my cameras [00:16:55 CET] <ShaneVideo> I have a growing TS file and I want to capture the last 5 seconds and continue recording until stopped. Filming baseball, trying to get a few seconds of "buffer" before the actual record command is sent. I'm trying to use -sseof -00:00:05 and -re but it never catches up to live [00:17:26 CET] <RossW> ok, so I've messed up. With your offered line, where do I set the x/y position of the overlayed image/logo (as opposed to the timestamp)? I've used: [00:17:33 CET] <RossW> ffmpeg -f image2pipe -r 25 -vcodec mjpeg -i - -i watermark.png -filter_complex [0:v][1:v]drawtext='%{pts\:hms}':x=w/2:y=h/2:fontcolor=white:box=1:boxcolor=black,overlay=(main_w*(1-0.95)):(main_h*(1-0.95)) -vcodec libx264 -crf 30 -movflags +faststart output.mp4 [00:17:52 CET] <RossW> and get: [00:17:53 CET] <RossW> Either text, a valid file or a timecode must be provided [00:18:00 CET] <RossW> Error initializing filter 'drawtext' with args '%{pts\:hms}:x=w/2:y=h/2:fontcolor=white:box=1:boxcolor=black' [00:18:06 CET] <RossW> Error initializing complex filters. [00:18:06 CET] <RossW> Invalid argument [00:26:17 CET] <RossW> http://pastebin.com/raw/CzKJBL5H [00:27:47 CET] <llogan> change "drawtext='%{pts\:hms}'" to "drawtext=text='%{pts\:hms}'" [00:27:54 CET] <llogan> also 2.8.6 is old [00:29:51 CET] <Jonno_FT1> I'm trying to use drawtext, and I get Key 'boxborderw' not found. [00:30:11 CET] <RossW> ok, that changed things. Now its complaining about the font. I best work out where they are :) [00:31:33 CET] <thebombzen_> Jonno_FT1: what's the full command and output? [00:32:22 CET] <Jonno_FT1> thebombzen_: http://pastebin.ws/fvd4lo [00:33:33 CET] <RossW> seems none were installed, which surprises me. Just building a fonts port now... [00:35:05 CET] <thebombzen_> Jonno_FTW: full command and output [00:35:09 CET] <thebombzen_> not just error message [00:35:12 CET] <Jonno_FTW> ok [00:35:56 CET] <Jonno_FTW> thebombzen_: http://pastebin.ws/cz7j2h [00:36:18 CET] <thebombzen_> use FFmpeg, not Libav [00:36:30 CET] <Jonno_FTW> well it's the one that comes on ubuntu 14.04 [00:36:46 CET] <thebombzen_> well then buildit yourself [00:37:00 CET] <faLUCE> hello. Does MPEG-TS support MJPEG codec? [00:37:00 CET] <Jonno_FTW> ok [00:37:04 CET] <Jonno_FTW> is that the problem then? [00:37:06 CET] <thebombzen_> we're not going to provide support here for a two-year-old version of a fork [00:37:16 CET] <Jonno_FTW> fair enough [00:37:49 CET] <thebombzen_> I have no idea if it's the problem, but it's a two-year-old version of a fork, so it's really not worth putting in the effort to try to figure it out [00:38:07 CET] <thebombzen_> because it's possible that it's a bug that has since been fixed, or has been fixed in FFmpeg [00:38:15 CET] <thebombzen_> faLUCE: yes [00:38:33 CET] <faLUCE> thebombzen_: thnks [00:38:48 CET] <thebombzen_> if you ever want to test it, try ffmpeg -f lavfi -i testsrc -c:v CODEC_NAME -f mpegts -y /dev/null [00:38:54 CET] <thebombzen_> (or NUL on windows instead of /dev/null) [00:39:17 CET] <thebombzen_> if it doesn't, it'll whine that it doesn't work [00:40:38 CET] <RossW> http://pastebin.com/raw/9M43qrMi <-- llogan/fflogger. [00:43:13 CET] <thebombzen_> faLUCE: although with mpegts I think you can technically put anything in it [00:43:39 CET] <thebombzen_> the issue is "will the video player play it" [00:45:56 CET] <llogan> RossW: you forgot your overlay before drawtext: "[0:v][1:v]overlay,drawtext..." [00:46:26 CET] <llogan> you were trying to provide two inputs to drawtext but it can only accept one input [00:46:52 CET] <RossW> llogan: how do I specify then the location of the overlay (graphic) x/y, compared to the text of the timestamp? [00:46:54 CET] <llogan> see "ffmpeg -h filter=drawtext" for details and/or "man ffmpeg-filters" [00:47:23 CET] <llogan> you have to set that in overlay [00:48:36 CET] <llogan> oh, you had overlay in there. move it so it is first. it will be someone simpler that way [00:48:57 CET] <RossW> so -filter_complex [0:v][1:v]overlay,drawtext=fontfile(blah blah blah)boxcolor=black,overlay=(x):(y)..... ??? [00:49:07 CET] <llogan> you only need one overlay [00:49:14 CET] <llogan> remove the end one [00:49:28 CET] <RossW> right... [00:53:05 CET] <llogan> Jonno_FTW: download this https://johnvansickle.com/ffmpeg/ or use this https://launchpad.net/~mc3man/+archive/ubuntu/trusty-media or follow this https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [00:53:23 CET] <RossW> brilliant! Now I just have to go back and understand how/why/what :) [00:53:55 CET] <RossW> Really appreciate the help, it's a steep learning curve, esp when I get interrupted every 11 seconds! [00:54:02 CET] <llogan> you'll get the hang of it [00:54:18 CET] <RossW> with help of the quality you guys just showed, I'm sure I will! [00:55:02 CET] <llogan> next step is to use a non-ancient ffmpeg [00:55:38 CET] <RossW> with the pts environment variable, can I start it from a specific time (other than 00:00) ?? [00:56:04 CET] <RossW> yes, I'll try to get the source for a later version and compile it. I'm currently running in a production environment. [00:57:25 CET] <llogan> apparently pts takes up to 3 arguments and the second is the offset. [00:57:27 CET] <Duality> any ideas why ffmpeg reads in a big piece of data before sending it out (on stdout in my case ? [00:57:32 CET] <RossW> Hmm, if I change the "pts\:hms" to "pts\:hm" it breaks. I only want hours:minutes. [00:58:24 CET] <llogan> you may have to use hms [01:09:12 CET] <furq> RossW: pts\:gmtime\:%H\\:%M [01:15:41 CET] <RossW> furq: thanks - any thoughts on how I can make it not increment at the default rate? Specifically, if I have (say) 1 frame per *minute*?? [01:19:20 CET] <RossW> yeah, my version must be too old... [01:19:22 CET] <RossW> [Parsed_drawtext_1 @ 0x809433660] %{pts} requires at most 2 arguments [01:19:30 CET] <RossW> doesn't like a 3rd. [01:22:36 CET] <Jonno_FTW> I'm having trouble building ffmpeg [01:23:06 CET] <Jonno_FTW> I get the error: "ERROR: libass not found using pkg-config", even though libass.pc is in my $PKG_CONFIG_PATH directory [01:23:33 CET] <Jonno_FTW> and "pkg-config --cflags libass" gives the right output [01:43:12 CET] <iive> Jonno_FTW: anything relevant in config.log ? [01:45:05 CET] <cahoots_> hi, how can i rewrite the timestamp for each frame to convert a video from 29.97 fps to 30fps, essentially slowing it down about 1/1000 [01:46:04 CET] <cahoots_> i want to alter the fps with a minimal change to the video itself. or if i simply set both the fps and the length, would that be the same? [01:46:51 CET] <Jonno_FTW> iive: not really [01:47:12 CET] <iive> it should give the exact error... [01:47:21 CET] <iive> and exact arguments used. [01:47:58 CET] <Jonno_FTW> iive: here's the last few lines: http://pastebin.ws/5pmtz0 [01:49:50 CET] <iive> looks like missing symbols. are you on slackware? [01:49:55 CET] <Jonno_FTW> ubuntu [01:51:25 CET] <iive> it seems like this is glib function(s) [01:53:34 CET] <Jonno_FTW> hm [01:55:00 CET] <iive> libharfbuzz.so seems to need them. I see glib-2.0 header includes in the compile commands. [01:55:25 CET] <iive> but no special link paths for glib. [01:56:47 CET] <Jonno_FTW> iive: nano chopped off the lines, here's the full thing: http://pastebin.ws/bdmjkz [02:04:27 CET] <iive> yes, these show -lglib-2.0 [02:05:06 CET] <iive> check if you have this library in the 64 library directory. e.g. [02:05:35 CET] <iive> ls -l /usr/lib/x86_64-linux-gnu/libglib-2.0* [02:06:29 CET] <Jonno_FTW> I do [02:08:17 CET] <Jonno_FTW> /usr/lib/x86_64-linux-gnu/libglib-2.0.so -> /lib/x86_64-linux-gnu/libglib-2.0.so.0 [02:09:36 CET] <iive> is there more? [02:09:47 CET] <Jonno_FTW> /usr/lib/x86_64-linux-gnu/libglib-2.0.a [02:10:39 CET] <iive> the first one is symbolic link. the file is in another directory, chec it with: [02:11:00 CET] <iive> ls -l /lib/x86_64-linux-gnu/libglib-2.0* [02:11:19 CET] <Jonno_FTW> /lib/x86_64-linux-gnu/libglib-2.0.so.0 -> libglib-2.0.so.0.4002.0 [02:11:54 CET] <iive> is that all? [02:12:03 CET] <Jonno_FTW> yes [02:12:40 CET] <iive> this is another symlink, but it points in the same directory. It points to libglib-2.0.so.0.4002.0 file [02:12:53 CET] <iive> that file is the actual library [02:13:52 CET] <iive> you might want to reinstall/repair glib-2.0 package [02:40:42 CET] <Jonno_FTW> so the error messabout pkg-config is wrong? [02:53:55 CET] <iive> Jonno_FTW: the message is misleading [02:54:46 CET] <iive> ffmpeg configure gets the parameters from pkg-config and tries to build a test program, the program fails to build with them. [02:55:30 CET] <iive> you seem to be missing a file... maybe it got lost during power down, maybe something removed it... [02:56:51 CET] <iive> sorry gtg [02:56:58 CET] <Jonno_FTW> thanks for the help [02:57:15 CET] <iive> the package system should be able to get that file [02:57:46 CET] <iive> but it might not be the only one. check `apt-get` options [02:58:45 CET] <iive> btw, i asked you if you use slackware, because it is the only distribution i know that doesn't check for package dependencies. [03:00:06 CET] <Jonno_FTW> I fixed it, was aproblem with libglib being old [03:42:44 CET] <Jonno_FTW> okay I build ffmpeg completely now [03:43:06 CET] <Jonno_FTW> When I make my mp4 there's a few blank seconds at the end of the file with no audio [03:45:11 CET] <mani36> hi firstly congrats. i am a final year from iit varanasi, india. i found your ideas interesting. i am good with cpp. in particular i want to work on ambisonic decoder. [03:46:37 CET] <mani36> i need little help to complete the qualificationtask [06:20:55 CET] <Jonno_FTW> I made a thing using ffmpeg!: https://github.com/jonnoftw/album2mp4 [06:42:09 CET] <_jam> I'm seeing the wrong "encoder" tag when I use ffprobe on an ffmpeg created mp3 using "-codec:a libmp3lame". It reports "Lavf56.25.101" instead of the approprate version of LAME. I couldn't find a bug on the tracker about this, but I don't have the capability to run the latest git version at this time to check if it is still a problem [06:42:43 CET] <_jam> applies to both constant bitrate and variable bitrate files [06:46:02 CET] <thebombzen_> _jam: the encoder tag is attached to the container, not the bitstream [06:46:14 CET] <thebombzen_> in this cause the bitstream was muxed into the container by Libavformat [06:47:31 CET] <_jam> thebombzen_: In the stream section, it also says encoder = "Lavc56.26" [06:48:43 CET] <thebombzen_> well that's because it was encoded by was libavcodec. in this case libavcodec delegated the encoding to the linked version of LAME but libavformat sees the libavcodec as the encoder [06:49:10 CET] <thebombzen_> because it sort of was. ffmpeg.c asked libavcodec to encode mp3, lavc said "LAME, you do it" and then reponsed to ffmpeg.c "sure thing" [06:49:46 CET] <_jam> ok, I understand the technical argument, but it seems misleading to consumers of the file [06:49:55 CET] <thebombzen_> realistically, this isn't a problem, because libmp3lame afaik is the only mp3 encoder that libavcodec has [06:50:06 CET] <thebombzen_> so any mp3 file that lists "lavc" as its encoder had to be encoded with LAME [06:50:17 CET] <thebombzen_> if you really care that much you can just set it manually [06:50:37 CET] <thebombzen_> especially since there is very little reason nowadays to encode mp3 so it's really not an issue [06:50:56 CET] <_jam> ok [06:51:18 CET] <_jam> thanks for the quick response [06:51:18 CET] <thebombzen_> keep in mind that you have to weight "ease of change" to "impact of change" to decide whether it's worth changing, because to change it, SOMEONE has to do it [06:51:41 CET] <thebombzen_> in this case it might be fairly easy but it's so low-impact that it's really not worth someone's time. and if it is, they'll do it. [06:51:50 CET] <_jam> yea, i understand that might not be a trivial change to make [06:53:51 CET] <k-man> how can i tell ffpmeg to write a filename ending in a different extention to what it would normaly use? [06:53:56 CET] <k-man> like m4b instead of m4a [06:55:02 CET] <thebombzen_> rename the file you use as output [06:55:18 CET] <thebombzen_> it won't autorecognize the format by file extension so you have to tell it the format with the -f option [06:55:30 CET] <thebombzen_> e.g. -f ipod out.m4b [06:55:33 CET] <thebombzen_> instead of out.m4a [06:55:55 CET] <k-man> ah thanks [06:56:06 CET] <k-man> thats the clue i was looking for thanks [07:00:32 CET] <k-man> where can i find a list of the format names? [07:36:01 CET] <c_14> ffmpeg -formats [07:36:21 CET] <c_14> https://ffmpeg.org/general.html#File-Formats [07:48:18 CET] <thebombzen_> keep in mind that some demuxers have generalized names [07:48:31 CET] <thebombzen_> given that webm is a special subset of matroska, the demuxer for both is matroska,webm, [10:23:47 CET] <hron84> Hi! I have a problem with streaming RTMP with FFMPEG. If I stream a video, it randomly cuts the last few seconds (terminates the video before the end) and starts the next one. I use -re switch in playing a video, I am not totally sure it can cause this issue. [10:33:11 CET] <thebombzen_> hron84: you should use -re on the command sending video to the rtmp server, not command receiving video from the rtmp server [10:34:09 CET] <thebombzen_> -re tells ffmpeg to read a file on the filesystem in realtime so the output will (ideally) go in realtime as well. useful for sending a file to a streaming server [10:34:50 CET] <thebombzen_> do not use -re for a live device because the whole point of it is to slow down filesystem reading to realtime. it cause cause buffering issues if you use -re from a live stream or a grab device [10:37:34 CET] <hron84> thebombzen: this is what i'm doing [10:37:44 CET] <hron84> I playing video with FlowPlayer [10:38:00 CET] <hron84> i used wrong word, i use -re in streaming. [10:59:42 CET] <chuckleplant> Good day all, I have implemented an h264 decoder and I've finally been able to cross-compile (for windows) with nvenc and cuvid enabled. [11:00:11 CET] <chuckleplant> I asked this a week or so ago.. forgot to take notes.. but how can I make my decoder use cuvid? [11:00:19 CET] <chuckleplant> It's based on this one http://roxlu.com/2014/039/decoding-h264-and-yuv420p-playback [11:01:13 CET] <chuckleplant> My question was whether it was possible to select the cuvid decoder when creating the codec context.. iirc answer is no? Is it selected automatically? [11:04:09 CET] <chuckleplant> Now I remember, there was "avcodec_find_decoder_by_name" [11:04:30 CET] <chuckleplant> Can I make it fallback to cpu if it fails to find it? [11:06:57 CET] <BtbN> Just use the normal find decoder if it doesn't find h264_cuvid or whatever you use [11:07:30 CET] <chuckleplant> I used pCodec = avcodec_find_decoder(AV_CODEC_ID_H264); [11:07:52 CET] <chuckleplant> And I'm not sure that one will ever pick the h264_cuvid decoder [11:08:19 CET] <BtbN> hardware decoders are never prefered [11:08:30 CET] <chuckleplant> My current machine does not have an Nvidia card, however the ffmpeg build does support cuvid. So if I search by name, the decoder is found. On runtime it does not work though [11:08:51 CET] <BtbN> you'll have to fall back if it fails to initialize [11:09:55 CET] <chuckleplant> which is the call that should fail? avcodec_alloc_context3? [11:10:17 CET] <BtbN> The one which calls init in the decoder [11:12:34 CET] <chuckleplant> ok, I see, avcodec_open. Thanks! [11:20:08 CET] <tested> how to burn srt file i tried but media player/web player didn't pick it [11:23:03 CET] <tested> anyone? [11:34:50 CET] <chuckleplant> BtbN: I'm finding it hard to find API documentation on using hw decoders. All that comes up is for ffmpeg.exe itself. Is there any known resource I can start on? My goal is to decode via cuvid, and render the resulting stream via OpenGL. I'm trying to avoid copying back to RAM from GPU ram when decoding frames [11:35:11 CET] <BtbN> cuvid works just like any other decoder [11:35:24 CET] <BtbN> There is no special treatment needed if you don't want hardware frame output [11:35:52 CET] <BtbN> For copying frames to OpenGL you need to utilize CUDA [11:36:15 CET] <BtbN> And implement the get_format callback to get the cuvid decoder to output cuda frames [11:57:18 CET] <chuckleplant> BtbN: Thanks! [13:24:07 CET] <IamTrying> http://paste.ubuntu.com/24095661/ - how do i make it as WebM? [13:25:00 CET] <IamTrying> do you -c:v libx264 -c:a libvo_aacenc -b:v 256k -b:a 32k -vf "scale=480:trunc(ow/a/2)*2" -tune zerolatency -preset veryfast -crf 23 -f flv rtmp://localhost/show/$name_low change it with -crf 23 -f webm? [13:25:39 CET] <BtbN> rtmp is flv [13:26:44 CET] <IamTrying> BtbN: i need the RTMP to DASH for WebM [13:26:51 CET] <IamTrying> using nginx-rtmp [13:27:04 CET] <BtbN> what? [13:27:21 CET] <BtbN> you can't stream webm via rtmp, the protocol is basically flv over tcp. [13:27:30 CET] <BtbN> If you want nginx to output dash, you have to do that in nginx [13:28:08 CET] <IamTrying> NO but here what they did then BtbN http://wiki.webmproject.org/adaptive-streaming/instructions-to-do-webm-live… [13:28:56 CET] <BtbN> They are not using nginx or rtmp at all there [13:30:23 CET] <IamTrying> http://paste.ubuntu.com/24095674/ - BtbN this is my nginx settings. but it wont work in Chrome cause there is no FLash anymore so i need to tell the ffmpeg in line 22 to convert it into WebM or am i completely wrong on that [13:30:50 CET] <BtbN> again: rtmp is only flv [13:31:01 CET] <BtbN> If you want dash output, you have to do that separately via nginx. [13:31:29 CET] <BtbN> and you already have hls there from the looks of it. So why not just use that? [13:31:49 CET] <IamTrying> BtbN: HLS have still the FLV stream? [13:31:55 CET] <BtbN> what? [13:32:04 CET] <IamTrying> and Google do not support Flash [13:32:14 CET] <BtbN> I have no idea what you are talking about. [13:32:31 CET] <BtbN> flv is an old flash container, yes. But it has nothing to do with the flash player. [13:33:30 CET] <IamTrying> http://paste.ubuntu.com/24095674/ - BtbN line 61 , line 66 should work with http://www.jplayer.org/? officially they support "HTML5: mp3, mp4 (AAC/H.264), ogg (Vorbis/Theora), webm (Vorbis/VP8), wav and Flash: mp3, mp4 (AAC/H.264), rtmp, flv" but with jplayer its not working in Google [13:33:47 CET] <IamTrying> BtbN: when i play same stream in old Chromium 38 it works but not anymore in new where Flash is removed [13:33:58 CET] <BtbN> So use some proper player that does not use flash [13:34:11 CET] <BtbN> Or just build your own with hls.js or something [13:34:29 CET] <IamTrying> OK [13:34:32 CET] <IamTrying> thank you [18:10:35 CET] <furq> http://images.anandtech.com/graphs/graph11170/85898.png [18:10:37 CET] <furq> wtf is "x264 3.0" [18:11:25 CET] <JEEB> probably the version of the benchmark package [18:12:10 CET] <furq> well that's some useful information [18:22:06 CET] <relaxed> nice results [18:24:01 CET] <furq> they're not all that positive for amd [18:24:12 CET] <furq> looks like a decent choice for the price though [18:24:41 CET] <furq> if nothing else it looks good enough that intel might have to respond to it with something other than hysterical laughter [18:25:17 CET] <relaxed> indeed [18:27:18 CET] <tftb> Hi! I'm getting getting really bad audio quality trying to record a screencast of an embedded video on a web page. The sound kind of chops every other second. My command line and relevant info here: http://pastebin.com/8rj4XH9U [18:28:04 CET] <tftb> I'm on OS X Sierra with ffmpeg 3.2.4. [18:44:32 CET] <JEEB> tftb: which audio encoder gets used? [19:19:43 CET] <faLUCE> Hello. when I stream flv on RTMP, who adds timestamps? flv or RTMP container? [19:20:10 CET] <JEEB> RTMP is not a container [19:20:15 CET] <JEEB> RTMP is a protocol that contains FLV [19:20:34 CET] <faLUCE> JEEB: yes, but does it add timestamps, like rtp? [19:21:15 CET] <JEEB> no fucking idea, as far as I know mostly the FLV timestamps are used [19:21:37 CET] <faLUCE> I suspect there's a duplication of timestamps [19:22:31 CET] <JEEB> well FLV timestamps have a very small timebase [19:22:34 CET] <JEEB> I think like 1000 or so [19:23:05 CET] <Mavrik> yp [19:26:08 CET] <faLUCE> it would be interesting to understand if there's a redundancy of timestamps in that stuff [19:26:52 CET] <faLUCE> for example: does RTMP work with "raw" h264 frames? [19:27:43 CET] <JEEB> RTMP is an Adobe thing and documented by Adobe [19:27:58 CET] <JEEB> as far as I can see RTMP is a thing purely to contain FLV [19:28:06 CET] <JEEB> and FLV supports AVC [19:28:16 CET] <faLUCE> I see [19:39:17 CET] <kepstin> my impression was that rtmp and flv are rather similar, flv is sort of a serialized file version of rtmp data :/ [19:39:50 CET] <kepstin> but they're definitely very closely related [20:31:20 CET] <faLUCE> kepstin: but both have timestamps. I don't understand why [20:33:48 CET] <faLUCE> rtp doesn't need a container because rtp has timestamps. http doesn't need timestamp because it wants a container (mpegts for example). Why the hell RTMP+flv have two timestamps? [20:35:37 CET] <kepstin> faLUCE: I don't think anyone here can explain the decisions that the people at adobe made in their proprietary protocol. [20:37:28 CET] <JEEB> does the protocol really have timestamps as well? anyways, adobe's docs would explain any reasoning if there is any :P [21:36:04 CET] <faLUCE> <JEEB> does the protocol really have timestamps as well? anyways, adobe's docs would explain any reasoning if there is any :P <---- but this channel is a shorter way to know it :-) :-) [21:36:37 CET] <JEEB> no, not this channel [21:37:36 CET] <faLUCE> JEEB: maybe some libav developer would answer.... [21:38:16 CET] <xtina> Hey guys. I'm trying to figure out if the following problem is solvable [21:38:39 CET] <xtina> I'm livestreaming w/ ffmpeg while tethered to my phone. Unfortunately I can't guarantee consistent speeds of over 1Mbps [21:39:12 CET] <xtina> I've tried specifying a constant bitrate, but this never works [21:39:41 CET] <xtina> When I DON'T specify a bitrate, the stream runs at >1x speed and elevated bitrates for the first 10s of stream as it clears the video/audio buffers that accumulated while ffmpeg was starting up [21:40:21 CET] <JEEB> with libx264 you set maxrate and bufsize [21:40:27 CET] <xtina> If I specify a bitrate (e.g. 800kbps) then ffmpeg runs at that bitrate even at the beginning, so it can't send data >1x speed and clear out the buffers at the first 10s of the stream [21:40:31 CET] <JEEB> which limits the encoder to maxrate over bufsize [21:40:38 CET] <xtina> this causes the audio buffer to fill and causes overruns. [21:42:07 CET] <xtina> JEEB: oh, fascinating! [21:42:09 CET] <xtina> that's perfect [21:42:24 CET] <DHE> unfortunately you are going to need to guarantee something, but libx264 can meet that requirement if you specify it properly. [21:42:43 CET] <DHE> usually -b:v 800k -maxrate:v 800k -bufsize:v 400k (= 1/2 second buffering allowed) [21:42:57 CET] <JEEB> xtina: so you have your primary rate control (be it CRF or some ABR or whatever) and then you limit that with maxrate and bufsize [21:43:20 CET] <JEEB> still won't help you if you get a wonky off latency [21:43:26 CET] <xtina> DHE: so with those settings i can get up to 1.2Mbps [21:43:36 CET] <xtina> JEEB: got it [21:43:41 CET] <JEEB> and some internal buffers go wee-wee, but it can help you with the rate control [21:43:44 CET] <xtina> does that only work if it's ffmpeg doing the encoding? [21:43:51 CET] <JEEB> anything using libx264 [21:43:51 CET] <xtina> what if i'm passing encoded audio/video into ffmpeg for muxing/streaming [21:44:03 CET] <JEEB> since it's a libx264 parameter (among other things) [21:44:08 CET] <xtina> i see [21:44:08 CET] <DHE> xtina: imagine you have a bucket containing 400 kilobits of H264 data. It fills at a rate of 800 kbit, but any single frame is allowed to take all the bits it needs to make a frame out of what's available in the bucket. the down side is that taking too many bits now may starve frames later. [21:44:17 CET] <DHE> so you would NOT want to mix this with -tune:v zerolatency [21:44:28 CET] <JEEB> xtina: if you don't control the encoder then good luck and have fun [21:45:48 CET] <xtina> got it, i think i understand. thanks, both, i'll test it out [21:45:58 CET] <DHE> or the more traditional way of looking at it, as long as you preload 1/2 second of the video before playback, a playing running at 800k won't run out of buffer. (using my above numbers) [21:46:31 CET] <xtina> right [21:47:08 CET] <xtina> OK. gonna exit but i'll try those params. thank again [22:07:15 CET] <bencc1> I have mkv from screen capture using ffmpeg [22:07:24 CET] <bencc1> large parts of it has no change in the screen [22:08:00 CET] <bencc1> is there a way to encode to mp4 while reducing the file size in the parts that has no change? [22:08:18 CET] <furq> any decent codec will do that anyway [22:08:36 CET] <furq> you could encode it vfr to get rid of the duplicate frames entirely [22:08:40 CET] <furq> with -vsync vfr [22:10:07 CET] <bencc1> this is what I currently use: [22:10:07 CET] <bencc1> ffmpeg -i in.mkv -c:v libx264 -preset medium -crf 23 -vf format=yuv420p -r 25 -c:a aac -strict experimental -b:a 96k -movflags +faststart out.mp4 [22:10:16 CET] <bencc1> so I should just add -vsync vfr? [22:10:34 CET] <bencc1> ffmpeg -i in.mkv -c:v libx264 -preset medium -crf 23 -vf format=yuv420p -vsync vfr -r 25 -c:a aac -strict experimental -b:a 96k -movflags +faststart out.mp4 [22:13:50 CET] <furq> you'll need a filter to remove duplicates as well [22:13:50 CET] <bencc1> furq: this is how I use it ^^ ? [22:14:03 CET] <bencc1> "-vf -vsync vfr" ? [22:14:36 CET] <furq> !filter mpdecimate [22:14:36 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#mpdecimate [22:15:15 CET] <bencc1> so I need both "-vsync vfr" and "-vf mpdecimate" ? [22:15:33 CET] <bencc1> maybe the default codec params should give me good enough result as you said at the beginning? [22:15:42 CET] <furq> yes, and probably [22:15:52 CET] <bencc1> ok, so I won't complicate things [22:15:52 CET] <bencc1> thankgs [22:15:57 CET] <furq> slower codec presets will do a better job of compressing that [22:17:21 CET] <bencc1> -preset slow or veryslow? [22:17:27 CET] <furq> sure [22:17:28 CET] <bencc1> compared to -preset medium? [22:17:40 CET] <ronagy> I'm getting a lot of buf_size warnings when trying to read a dnxhd raw stream [22:17:41 CET] <bencc1> I'll check the difference between the presets. thanks [22:17:45 CET] <furq> there's also -preset slower [22:17:51 CET] <ronagy> looking at the code I can see that ff_raw_read_partial_packet is probably used to read out packets [22:17:51 CET] <furq> and placebo, but don't use that [22:17:59 CET] <bencc1> slower is between slow and veryslow? [22:18:12 CET] <furq> yeah [22:18:19 CET] <ronagy> but I'm not seeing how the packets is combined into the buf_size dnxhd_decode_header expects>? [22:19:15 CET] <JEEB> there's usually a parser between demuxer and decoder [22:19:45 CET] <JEEB> in case non-full packets can come out of a demuxer [22:21:10 CET] <ronagy> and where is that parser in case of dnxhd? [22:21:53 CET] <JEEB> libavcodec/dnxhd_parser.c I would guess [22:22:14 CET] Action: JEEB did a quick `find . -iname '*dnxhd*'` in the root FFmpeg dir [22:22:42 CET] <ronagy> ah, don't know how I missed that! thanks [22:23:49 CET] <alexpigment> hello everyone. I'm trying to cross-compile for Windows on Ubuntu 16.04 using ffmpeg-windows-build-helpers. i can compile just fine for Win64, but Win32 fails every time with "ERROR: libass not found using pkg-config". others have this issue, but none of the suggestions on google seem to help [22:24:28 CET] <JEEB> 3rd party build script, go ask for support from the people maintaining those scripts [22:25:05 CET] <alexpigment> jeeb. that's fair, i suppose. immediately after getting the error it said to come here, so i figured this wasn't anything to do with the script [22:25:12 CET] <alexpigment> anyway, thanks for your help [22:26:46 CET] <bencc1> "-threads 1" will ensure I only use one cpu core? [22:27:14 CET] <bencc1> I have several parallel transcoding jobs and I don't want one to affect others [22:30:17 CET] <alexpigment> general ffmpeg question: is it possible to compile a shared ffmpeg that incorporates both 8-bit and 10-bit x265? i'd ideally like to have it automatically switch to 10-bit when a command line triggers 10-bit via a profile like main10 [22:32:31 CET] <JEEB> alexpigment: I thought that was just about building with the high bit depth mode enabled, since a high bit depth x265 would be able to output 8-10bit [22:32:37 CET] <JEEB> (and 12bit nowadays) [22:33:08 CET] <alexpigment> jeeb: as far as I can tell, you can't do 8-bit on a 10-bit x265 [22:33:13 CET] <alexpigment> this is certainly true with static builds [22:33:38 CET] <alexpigment> 10-bit HEVC is required (among other parameters) for 4k HDR [22:34:12 CET] <alexpigment> so obviously, it would be ideal to save space and not have two sets of ffmpeg shared just for x265 8-bit and 10-bit [22:34:45 CET] <furq> i don't think that's right [22:35:05 CET] <alexpigment> furq: do you mind elaborating? [22:35:11 CET] <furq> x264 is either/or [22:35:25 CET] <furq> but i'm pretty sure x265 can still do 8-bit output if you build with high bit depth enabled [22:36:17 CET] <furq> you can also build a shared ffmpeg which does 8/10-bit x264 by having two copies of libx264.so and abusing LD_LIBRARY_PATH [22:36:43 CET] <JEEB> yes, it's just not as optimized since you can't ignore the >8bit stuff, if I recall correctly. and yes, x264 is (currently) limited to one bit depth, but they're having patches on the mailing list for 8 and 10 bit capabilities in a single binary [22:38:06 CET] <alexpigment> jeeb, ok thanks for the confirming that for me. do you a link somewhere about the patches? [22:38:29 CET] <furq> i assume that refers to the x264 binary and not the lib [22:39:01 CET] <alexpigment> for what it's worth, i just did a test and i tried to set "Main" HEVC profile on a 10-bit version of ffmpeg and it errors out. setting it to main10 works. [22:39:02 CET] <JEEB> pretty sure it was the lib too [22:39:14 CET] <JEEB> alexpigment: that might be in the libavcodec wrapper [22:39:27 CET] <JEEB> x265 at least the command line encoder is capable of both 8bit and 10bit [22:39:37 CET] <JEEB> alexpigment: did you try -pix_fmt yuv420p instead of the profile? [22:39:53 CET] <alexpigment> i did yesterday, but i'll try again [22:39:53 CET] Action: JEEB hasn't looked at the libx265 wrapper [22:40:30 CET] <alexpigment> jeeb: yep, same error when specifying yuv420p [22:40:40 CET] <alexpigment> it assumes yuv420p10le i believe [22:42:56 CET] <JEEB> anyways, I'd say the libx265 wrapper needs work then, and libx264 when the multi-bit-depth changes get in [22:43:29 CET] <alexpigment> k, well i appreciate the heads up [22:43:53 CET] <furq> i imagine you can use the LD_LIBRARY_PATH trick for libx265 as well [22:43:54 CET] <alexpigment> i'll check back in in a few months and see if the status has changed [22:44:44 CET] <alexpigment> furq: i'm a bit of a noob when compiling. i'm only compiling my own because zeranoe seems oblivious to the fact that the only selling point for 4K TVs is HDR and therefore 10-bit is required ;) [22:44:52 CET] <furq> oh, zeranoe [22:45:02 CET] <alexpigment> do you mind elaborating on the LD_LIBRARY_PATH trick? [22:45:08 CET] <furq> well if you're on windows then there is no such thing [22:45:26 CET] <alexpigment> i'm compiling on ubuntu, but compiling for win64 and win32 [22:45:45 CET] <furq> it's a way to force loading of different shared libs at runtime [22:45:51 CET] <furq> so it'll only work if you're running on *nix [22:46:03 CET] <alexpigment> ok, so this is after compilation [22:46:04 CET] <alexpigment> gotcha [22:46:06 CET] <furq> i don't think there's any windows analogue [22:50:07 CET] <alexpigment> has anyone had much experience rendering with libx265 on a system with lots of logical cores (e.g. 8-cores/16-threads or more)? the speed on my i7-3770 is really slow, and i'm not sure how much improvement i'd see going to an 8-core i7 [22:50:50 CET] <alexpigment> and of course, nvenc and qsv are both way too primitive to use in place of x265 [22:51:14 CET] <ronag> This looks like a bug in ffmpeg, no? https://gist.github.com/ronag/b83250c84dcb0397e97fe21dda9f0a30 report ticket? [22:51:48 CET] <ronag> I'm muxing to dnxhd, pipe to ffmpeg, demux ffmpeg [22:51:49 CET] <ronag> "Invalid data found when processing" [22:53:50 CET] <gp5st> hello. I'm trying to create an HLS fileset from a video `ffmpeg -i input.mp4 -b:v 256k -flags -global_header -map 0:0 -map 0:1 -s 640x480 -f segment -segment_time 4 -segment_list_size 0 -segment_list vp8/stream.m3u8 vp8/stream%05d.webm` but it's only creating the first file and encoding the whole video to it and not creating the m3u8 file. is there something stupid I'm (not) doing? [22:54:36 CET] <slalom> oh wow, i've been doing HLS stuff lately and was hoping someone else would talk about it at some point [22:55:02 CET] <slalom> i gave up on it though because it couldn't create the iframe_index, so i broke down and we are licensing unified-streaming stuff for the HLS part [22:55:21 CET] <slalom> if you're on osx you can use apple's HLS tools on the commandline for it too [22:56:06 CET] <slalom> let me look at how far i got [22:56:13 CET] <slalom> you're not specifying hls [22:56:18 CET] <gp5st> slalom: linux and bsd here [22:56:29 CET] <gp5st> sorry, I'm new to this all, iframe_index? [22:56:48 CET] <slalom> it's another file that's created that for whatever reason our stremaing server needs/uses [22:56:51 CET] <slalom> streaming* [22:57:07 CET] <slalom> real HLS packagers that aren't ffmpeg create it [22:57:48 CET] <furq> webm over hls? [22:57:53 CET] <furq> that doesn't seem like something that'll work [22:59:13 CET] <slalom> ffmpeg -i Episode_10.mov -profile:v high -level 4.0 -b:v 8600k -c:a aac -b:a 128k -start_number 0 -hls_flags split_by_time -hls_time 10 -hls_list_size 0 -hls_playlist_type vod -hls_segment_filename fileSequence%%d.ts -f hls prog_index.m3u8 [22:59:24 CET] <slalom> is the last thing i was working on [23:00:03 CET] <gp5st> this all seems to work for ff and mpeg4, but chromium doesn't seem to have mpeg4 support [23:00:26 CET] <gp5st> furq: oh :( [23:01:31 CET] <slalom> gp5st: you're using the normal muxer [23:01:34 CET] <slalom> segmenter [23:01:42 CET] <slalom> have you tried using the actual hls stuff [23:01:57 CET] <slalom> in ffmpeg i mean [23:02:14 CET] <gp5st> slalom: not really, because I don't know what I'm doing :-| [23:02:23 CET] <alexpigment> i always assumed HLS required an F4V container for H.264 - maybe i'm wrong on that [23:02:33 CET] <furq> hls is mpegts [23:02:44 CET] <furq> or fmp4, recently, but i doubt anything supports that yet [23:02:53 CET] <furq> it does require h264 and aac though [23:03:12 CET] <furq> gp5st: what are you actually trying to do [23:03:26 CET] <gp5st> furq: I was trying to get this to work in chromium [23:03:33 CET] <alexpigment> furq - you're right. i was thinking of another type of streaming that's done through flash [23:03:39 CET] <furq> you're thinking of rtmp [23:03:42 CET] <gp5st> though, I guess most people have chrome and h264 should work? [23:03:51 CET] <furq> does h264 not work in chromium [23:04:06 CET] <gp5st> furq: no, it doesn't, hence my experiment here [23:05:35 CET] <furq> there are apparently windows chromium builds with h264 and aac enabled [23:05:44 CET] <furq> and on linux it just uses the system ffmpeg libs afaik [23:06:09 CET] <furq> but if you're not doing livestreaming then just convert it to webm the usual way [23:08:44 CET] <gp5st> furq: eh, I think I can just do h264 and call it a day [23:17:30 CET] <peetah> hi, I may have found a closed source software using ffmpeg without a word in its documentation and various licence documents [23:18:01 CET] <durandal_170> peetah: name? [23:18:22 CET] <peetah> as ffmpeg is licensed under LGPL is should only be a matter of adding relevant notices [23:19:01 CET] <peetah> but from my understanding libpostproc, which they include as a dll along other ffmpeg dlls, is under GPL [23:19:14 CET] <peetah> therefore it makes their sofware GPL as well [23:19:17 CET] <peetah> am i right ? [23:20:16 CET] <furq> yeah [23:20:21 CET] <peetah> durandal_170: no name for now, I want to be 100% sure about my claims [23:21:21 CET] <furq> is it commercial software [23:21:31 CET] <durandal_170> does it have build flags ? [23:22:13 CET] <peetah> how can I check this ? this is a windows only software: can it be checked by grepping something in the dll [23:22:17 CET] <peetah> ? [23:22:40 CET] <furq> if it's bundled with an ffmpeg binary then you can check that [23:23:18 CET] <peetah> here is what I get : FFmpeg version N-72662-g7be0f48 [23:23:51 CET] <durandal_170> peetah: whats bellow that? [23:23:54 CET] <furq> there should be build options below that [23:25:08 CET] <peetah> i got this by grepping FFmpeg from the output of `strings postproc-53.dll` [23:25:15 CET] <furq> grep enable [23:25:51 CET] <peetah> among all, there is --enable-gpl ! [23:26:09 CET] <furq> you can't build libpostproc without enable-gpl so that's no great surprise [23:26:27 CET] <peetah> --disable-static --enable-shared --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libdcadec --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmfx --enable-libmp3lame [23:26:33 CET] <peetah> --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs [23:26:39 CET] <peetah> --enable-libxvid --enable-lzma --enable-decklink --enable-zlib [23:27:05 CET] <furq> a bunch of external gpl libs as well [23:27:16 CET] <furq> so yeah if this is closed source then they're 100% in violation [23:27:26 CET] <furq> (ianal) [23:27:31 CET] <peetah> yes but they don't seem to be included in the soft distribution [23:27:46 CET] <furq> did you download those dlls from them [23:27:55 CET] <furq> if you did then they need to publish the source [23:28:11 CET] <furq> if you have to provide your own ffmpeg libs then that's not so simple [23:28:18 CET] <peetah> They distribute their software to their client on a CD [23:28:33 CET] <furq> they have to make the source available on request then [23:29:42 CET] <peetah> they do not seem to follow any of the advices given at https://www.ffmpeg.org/legal.html [23:29:50 CET] <furq> shock horror [23:30:22 CET] <furq> they definitely need to be providing ffmpeg sources [23:30:28 CET] <peetah> does the use of libpostproc implies that their distributed software must be GPL ? [23:30:33 CET] <furq> i forget the specifics around whether they need to provide the source to their application, but i suspect they do [23:30:55 CET] <furq> i know there are ways around that with lgpl ffmpeg, but i don't think those apply to the gpl [23:31:13 CET] <durandal_170> peetah: they have libx264 and thats gpl [23:31:52 CET] <furq> yeah if they're building with --enable-gpl then they're linking to gpl software [23:32:18 CET] <furq> or loading it at runtime, but i don't think the gpl makes a distinction [23:37:49 CET] <peetah> a search for x264 gives dlls from visioforge, libvlccore, swresample and swscale [23:40:46 CET] <peetah> I really don't want to mess by accusing them on wrong basis, because their soft is really great in their domain, and the developers team is very open to suggestions, reactive and full of respect for its users base [23:41:39 CET] <furq> these things happen by accident sometimes [23:42:00 CET] <furq> if you want to be respectful then let them know privately [23:42:45 CET] <peetah> I'm sure this is more a 'We have no clue about what those licences implie' rather than 'gimme it's free' [23:43:39 CET] <peetah> durandal_170: do you have a legal team that is used to deal with these cases ? or are you relying on EFF or others ? [23:43:55 CET] <furq> if you're saying half the libs they're building with aren't being distributed then it sounds like someone just enabled a bunch of build flags which aren't needed [23:44:07 CET] <furq> in which case they might not even need to build with enable-gpl [23:44:46 CET] <durandal_170> peetah: trac bug report [23:46:49 CET] <peetah> ok so I'll contact them privately first, and then if things can't be solved, I will file a bug report on trac [23:47:13 CET] <peetah> durandal_170 , furq: thanks for your advices [00:00:00 CET] --- Fri Mar 3 2017

1 0

ffmpeg-devel.log.20170301
by burek 02 Mar '17

02 Mar '17

[06:04:11 CET] <wm4> "We provide our custom Boost libraries." WAT [06:06:04 CET] <Compn> haha [06:06:06 CET] <Compn> wheres that [06:07:55 CET] <wm4> one of the libturing threads on ffmpeg-devel [07:46:18 CET] <wm4> michaelni: ok to push "doc: clarify development rules"? [09:24:31 CET] <kierank> wm4: wow [09:25:08 CET] <wm4> kierank: yes? [09:25:29 CET] <kierank> Custom boost [09:25:31 CET] <kierank> Insane [09:26:15 CET] <wm4> yeah, I feel slightly offended that they're using Turing's name [09:31:01 CET] <JEEB> oh that thing [09:38:55 CET] <jkqxz> As long as they actually build the things in so that it doesn't interfere with anything else then whatever. [09:46:32 CET] <cone-291> ffmpeg 03Carl Eugen Hoyos 07master:d100dc6c9955: Makefile: Clean compat subdirectory. [11:29:43 CET] <wm4> I'm still trying to merge those filter init patches [11:29:55 CET] <wm4> I think many timestamp issues are caused by "ffmpeg: do packet ts rescaling in write_packet()" [11:30:18 CET] <wm4> the main issue is that a muxer can update the timebases in write_headers [11:30:43 CET] <nevcairiel> didnt you compensate for that by moving the call already [11:30:49 CET] <wm4> before the patches write_headers was called before even encoding something - now it's called only after most of that happens for every AVStream to mux [11:31:02 CET] <wm4> and that compensation works only if there's 1 stream to mux [11:31:49 CET] <wm4> if there are multiple streams, then mux_timebase can only be correctly set for the last stream that's initialized [11:31:58 CET] <nevcairiel> so the main problem is that timestamps vary in precision a bit, because they are rescaled in one extra timebase in between? [11:34:25 CET] <wm4> yes [11:34:42 CET] <nevcairiel> it makes sense for muxers to only determine the timebase in write_headers, only then do they know the stream properties [11:35:09 CET] <wm4> it's the current API anyway, so no changing that [11:35:28 CET] <wm4> it often depends on codec parameters too [11:35:38 CET] <nevcairiel> yeah, audio sample rates and whatnot [11:36:04 CET] <wm4> I wonder if setting a random high timebase would hurt [11:36:17 CET] <wm4> like AV_TIME_BASE [11:36:35 CET] <nevcairiel> and the problem then is that with multiple streams you already have a bunch of packets queued up before you know the final timebase? [11:36:51 CET] <wm4> yes, potentially [11:37:30 CET] <michaelni> wm4, about "doc: clarify development rules", i dont think i have the authority to say ok or not ok. but it seems some people on the ML were not in favor of the patch [11:37:54 CET] <wm4> michaelni: their comments were invalid [11:38:12 CET] <wm4> they were complaining about the current dev policy, which was offtopic [11:38:22 CET] <wm4> so basically nobody rejected/approved the patch [11:38:33 CET] <wm4> and MAINTAINERS has no maintainer [11:38:39 CET] <wm4> what am I supposed to do [11:39:00 CET] <nevcairiel> instead of setting mux_timebase to some guessed output timebase, why not use the input timebase? [11:39:16 CET] <nevcairiel> that still avoids a rescale, potentially [11:39:29 CET] <wm4> nevcairiel: that's also "random" (because the timebase can be changed by filters or encoder), but yeah [11:39:54 CET] <nevcairiel> at the time it is set, the filters would already have initialized it [11:39:58 CET] <wm4> I'm not really sure what timebase it uses now [11:40:22 CET] <wm4> filters are lazily initialized, and I think there can be multiple filter graphs [11:40:25 CET] <nevcairiel> if the timebase changes in the middle of encoding for some reason, it w ould never compensate either way [11:41:24 CET] <nevcairiel> basically you have filter timebase -> mux timebase -> output timebase [11:41:28 CET] <nevcairiel> ideally two of those are the same [11:41:38 CET] <nevcairiel> if mux and output cant really be the same, why not filter and mux [11:42:39 CET] <wm4> hm yeah I have no idea where it initializes the timebase before that [11:43:47 CET] <nevcairiel> with the new initialization order, I would think at the time the outputstream is being created, you already know the final and proper input timebase [11:44:09 CET] <wm4> dammit why does ffmpeg.c have to be (almost) a single file [11:46:46 CET] <wm4> "enc_ctx->time_base = av_inv_q(ost->frame_rate);" interesting [11:47:14 CET] <wm4> (not sure if that's a good idea over the filter time_base, but that's what it does) [11:47:37 CET] <wm4> (though it falls back to filter timebase if unset) [11:49:19 CET] <wm4> still getting a fate failure with subtitles lol [11:49:53 CET] <michaelni> wm4, i dont know but if you dont want anyone to dispute the validity of a change in the future then a vote or clear consensus with sufficient time for people to comment may be needed. It may be enough to repost with a clear statement that if noone objects in X days it will be pushed and will be part of the policy people have to comply to or something [11:50:19 CET] <wm4> michaelni: I'm not sure if you're trolling me [11:51:00 CET] <wm4> surely we shouldn't have to vote for patches that are not properly reviewed [11:52:00 CET] <wm4> demuxer+ffmpeg -> ist_index:1 type:subtitle pkt_pts:1832831 pkt_pts_time:20.3648 pkt_dts:1832831 pkt_dts_time:20.3648 off:-100100 off_time:-0.1001 [11:52:22 CET] <wm4> muxer <- type:subtitle pkt_pts:2037 pkt_pts_time:20.37 pkt_dts:2037 pkt_dts_time:20.37 size:70 [11:52:46 CET] <wm4> this was 20.36 before my change [11:52:49 CET] <michaelni> wm4 i was just tryng to reply to "<wm4> what am I supposed to do", i dont want to be involved in this at all [11:52:54 CET] <wm4> so rounding is done differently, "somewhere" [11:53:42 CET] <wm4> michaelni: then why are you [11:54:09 CET] <nevcairiel> which timebase are you using now for mux [11:54:32 CET] <wm4> I mean, this is quite funny, I'm trying to clarify the rules, yet I don't know if I can push the clarification because nobody knows the rules [11:54:47 CET] <wm4> nevcairiel: the encoder's timebase, which for subtitles is always 1/000 [11:54:48 CET] <michaelni> wm4, because you pinged me "<wm4> michaelni: ok to push "doc: clarify development rules"?" [11:54:51 CET] <wm4> err, 1/1000 [11:55:22 CET] <wm4> michaelni: point taken [11:55:50 CET] <wm4> you're still the defacto project leader, though [11:56:09 CET] <wm4> because there's nobody else [11:56:39 CET] <wm4> hm, subtitle timebase of 1/90000 can only be wrong due to things like dvb subs too [11:58:58 CET] <nevcairiel> if mux_timebase is 1/1000 and subtitles use 1/1000 for encoding, how cna it end up wrong [11:59:24 CET] <nevcairiel> oh [11:59:27 CET] <nevcairiel> subtitles use AV_TIME_BASE [11:59:29 CET] <nevcairiel> not 1/1000 [12:00:02 CET] <wm4> where? [12:00:10 CET] <nevcairiel> in do_subtitle_out [12:00:11 CET] <wm4> the encoder context gets 1/1000 [12:00:15 CET] <nevcairiel> pkt.pts = av_rescale_q(sub->pts, AV_TIME_BASE_Q, ost->mux_timebase); [12:00:46 CET] <wm4> ah [12:01:02 CET] <wm4> just tried with the input timebase [12:01:03 CET] <nevcairiel> not sure whatever is in the context, but thats what it uses [12:01:04 CET] <wm4> -Dialogue: 0,0:02:23.48,0:02:26.53,Default,,0,0,0,,C 09...\N8=0 <=>3> 2@5<5. [12:01:04 CET] <wm4> +Dialogue: 0,0:02:23.48,0:02:26.52,Default,,0,0,0,,C 09...\N8=0 <=>3> 2@5<5 [12:02:05 CET] <wm4> setting the encoder tb to AV_TIME_BASE_Q makes it pass [12:02:06 CET] <wm4> whatever [12:02:25 CET] <nevcairiel> i guess subtitle encoders just never use the tb? [12:02:30 CET] <wm4> (mux_timebase is the same as the encoder tb in my current changes) [12:02:40 CET] <wm4> quite possible [12:03:02 CET] <nevcairiel> we moved all possible formats to out-of-band timestamps [12:05:40 CET] <nevcairiel> I imagine it worked in libav because st->timebase is just set to enc_ctx->timebase somewhere [12:05:44 CET] <nevcairiel> and we dont do that for reasons [12:05:54 CET] <wm4> or libav doesn't even test that [12:06:04 CET] <nevcairiel> also possible [12:06:29 CET] <wm4> now binsub-movtextenc failed [12:06:32 CET] <wm4> with a changed hash [12:06:37 CET] <nevcairiel> but using enc_ctx timebase (and whatever equaivalent for streamcopy) for mux timebase is probably ok [12:07:24 CET] <nevcairiel> what does that test? [12:07:25 CET] <wm4> this test passes if I use the input tb [12:07:35 CET] <wm4> ffmpeg -nostdin -nostats -cpuflags all -hwaccel none -threads 1 -thread_type frame+slice -i ../fate//sub/MovText_capability_tester.mp4 -map 0 -scodec mov_text -f mp4 -flags +bitexact -fflags +bitexact -movflags frag_keyframe+empty_moov md5: [12:07:59 CET] <wm4> probably rounding [12:09:59 CET] <nevcairiel> depending on what exactly it writes, it may also pick up the changed encoder timebase [12:11:15 CET] <wm4> uh [12:11:19 CET] <wm4> the mp4 files are the same [12:11:42 CET] <wm4> right, because I did something dumb [12:12:53 CET] <wm4> -time_base=1/1000 [12:12:53 CET] <wm4> +time_base=1/1000000 [12:12:54 CET] <wm4> yep [12:13:44 CET] <wm4> I wish fate had a way to resume from a given point [12:14:07 CET] <nevcairiel> makefile based, no such luck [12:17:12 CET] <wm4> aaaaand sub2video fails [12:17:22 CET] <wm4> probably just changed timebase [12:23:16 CET] <wm4> and fate-copy-trac4914-avi (just mentioning because I find the name of the test funny) [12:23:32 CET] <BtbN> Are you at the lazy filter init regressions again? [12:23:37 CET] <wm4> yes [12:23:42 CET] <BtbN> Sounds like fun [12:58:48 CET] <BtbN> I really wonder what the hell kind of encoding cl uses. winpty managed to convert it to something useful, but I can't find any input format for iconv that converts it to utf-8 [12:59:17 CET] <wm4> so I have no idea why fate-copy-trac4914-avi failed, some packets got reordered and some timestamps change slightly [12:59:30 CET] <wm4> I'll just assume nobody will object [12:59:41 CET] <wm4> BtbN: cl? [12:59:47 CET] <BtbN> MSVC compiler [12:59:56 CET] <wm4> probably your local 8 bit codepage [13:00:01 CET] <BtbN> nope [13:00:21 CET] <wm4> maybe iconv doesn't understand it correctly [13:00:32 CET] <BtbN> windows-1252 to utf-8 doesn't work [13:00:40 CET] <wm4> meaning? [13:01:16 CET] <BtbN> cl |& head -n1 | iconv -f windows-1252 -t utf-8 -> iconv: (stdin):1:64: cannot convert [13:02:21 CET] <wm4> that means it uses bytes not defined by that codepage? [13:02:30 CET] <BtbN> I guess so, yes [13:02:39 CET] <BtbN> I tried basically all codepages there are, none works [13:04:30 CET] <BtbN> Might be CP20273/windows-1141 [13:04:35 CET] <BtbN> which iconv does indeed not support [13:05:17 CET] <wm4> what's the offending byte? [13:05:27 CET] <BtbN> The one for ü [13:06:34 CET] <BtbN> https://bpaste.net/show/04590852adb2 [13:07:02 CET] <wm4> 0x81? [13:07:04 CET] <BtbN> yes [13:07:36 CET] <BtbN> Might as well just say fuck it and strip away all non-utf8 characters from the cc ident... [13:07:51 CET] <BtbN> They use the local codepage per language anyway, so adding logic for that to configure would be insane [13:08:00 CET] <wm4> heh [13:09:24 CET] <BtbN> chcp says I'm on CP850 [13:09:55 CET] <BtbN> indeed, iconv -f CP850 -t utf-8 works [13:10:14 CET] <BtbN> That's "Multilingual (Latin I)" [13:10:20 CET] <BtbN> So maybe it does work for more than German [13:11:08 CET] <nevcairiel> 850 has ü at 0x81 [13:13:02 CET] <wm4> demuxer+ffmpeg -> ist_index:0 type:video pkt_pts:537660 pkt_pts_time:5.974 pkt_dts:531654 pkt_dts_time:5.90727 off:-419044 off_time:-0.419044 [13:13:02 CET] <wm4> [mpeg @ 0x55b130cae360] Non-monotonous DTS in output stream 0:0; previous: 531531, current: 531531; changing to 531532. This may result in incorrect timestamps in the output file. [13:13:02 CET] <wm4> muxer <- type:videdemuxer+ffmpeg -> ist_index:0 type:video pkt_pts:537660 pkt_pts_time:5.974 pkt_dts:531654 pkt_dts_time:5.90727 off:-419044 off_time:-0.419044 [13:13:02 CET] <wm4> [mpeg @ 0x55b130cae360] Non-monotonous DTS in output stream 0:0; previous: 531531, current: 531531; changing to 531532. This may result in incorrect timestamps in the output file. [13:13:04 CET] <wm4> muxer <- type:video pkt_pts:537537 pkt_pts_time:5.97263 pkt_dts:531532 pkt_dts_time:5.90591 size:14002 [13:13:07 CET] <wm4> o pkt_pts:537537 pkt_pts_time:5.97263 pkt_dts:531532 pkt_dts_time:5.90591 size:14002 [13:13:11 CET] <wm4> crap [13:13:14 CET] <wm4> (pasted a bit too much) [13:13:33 CET] <wm4> anyway, I'm probably missing how timestamp rounding in ffmpeg.c works [13:14:13 CET] <wm4> these warnings are new with the rescale changes libav patch + setting mux_timebase to encoder output [13:43:27 CET] <cone-645> ffmpeg 03Carl Eugen Hoyos 07master:a2ca9e11ff71: Makefile: Clean compat/atomics/pthread subdirectory. [14:03:43 CET] <Compn> wm4 : since you want to change policy, you need a majority of active devs to agree with you [14:04:08 CET] <Compn> <insert definition of active here> :P [14:04:11 CET] <Compn> or just devs.. [14:04:20 CET] <wm4> Compn: for the 100ths time, I don't want to change policy [14:04:29 CET] <wm4> at least not with that patch [14:04:37 CET] <Compn> i havent read the patch , let me read it... :D [14:04:42 CET] <wm4> I'm trying to find out what the fucking rules are in this project [14:05:58 CET] <Compn> well you are setting the time periods of various things. including what an active developer is [14:06:42 CET] <Compn> just the 6 month thing i guess. i'm not sure what would be a good timeframe [14:06:54 CET] <wm4> well that's as arbitrary as the actual policy, apparently [14:07:32 CET] <Compn> also the line about 'this only applies to people with git access' could go, as its redundant to reality [14:08:17 CET] <cone-645> ffmpeg 03Michael Niedermayer 07master:2c00b3730240: avcodec/avpacket: Check metadata key in av_packet_unpack_dictionary() [14:08:18 CET] <cone-645> ffmpeg 03Michael Niedermayer 07master:4bd3f1ce3e68: avcodec/h264_direct: Fix runtime error: left shift of negative value -14 [14:08:19 CET] <cone-645> ffmpeg 03Michael Niedermayer 07master:7b5ff7d57355: avcodec/vp8: Check for bitsteam end in decode_mb_row_no_filter() [14:08:30 CET] <Compn> i mean you have to agree, no time frame set > 6 months timeframe set is technically a change in policy. please be careful with your words :P [14:08:36 CET] <wm4> well the text is directed to external contributors too [14:08:51 CET] <wm4> Compn: I acknowledge that in my patch? [14:10:07 CET] <Compn> external contributors , get git access when they become maintainers, usually though [14:10:18 CET] <Compn> if that sentence makes sense [14:11:26 CET] <Compn> to answer your question about michaelni. he very publically stated that he is not project leader (this news hit a lot of major tech news websites a while back) and will not override the consensus of the developers in the project. [14:12:28 CET] <wm4> Compn: there's nobody else who could arbitrate [14:12:35 CET] <Compn> thats the point [14:12:43 CET] <wm4> that he isn't project leader is de-facto wrong, and de-facto bullshit [14:12:59 CET] <Compn> now you're ignoring his wishes not to be project leader. thats not good [14:13:18 CET] <Compn> the only arbitration is consensus among ffmpeg devels [14:13:30 CET] <Compn> or ... electing a new project leader [14:13:33 CET] <wm4> ffmpeg devs are unable to come to a consnsus [14:13:35 CET] <Compn> by consensus of ffmpeg devs... [14:13:41 CET] <wm4> *conensus [14:13:47 CET] <wm4> *consensus (this time) [14:13:48 CET] <wm4> this has been proven before [14:14:02 CET] <wm4> project leaders are needed because of such issues [14:14:12 CET] <Compn> then policy does not change... if there is no consensus [14:14:37 CET] <Compn> maybe make it a suggestion in your patch [14:14:59 CET] <Compn> "if the maintainer or author of the code has not made changes or communications within 2 years, feel free to push changes...' [14:15:04 CET] <Compn> or [14:15:12 CET] <wm4> why not make it 4 years [14:15:12 CET] <Compn> "if the maintainer or author of the code has not made changes or communications within 2 years, use your best judgement to push changes...' [14:15:18 CET] <wm4> at least I still get michaelni for a rule violation this way [14:15:25 CET] <Compn> i picked 2 years... [14:15:38 CET] <Compn> since its my review of the patch , i get to pick my terms [14:15:45 CET] <wm4> you pulled 2 years out of your ass, correct [14:15:51 CET] <wm4> just like I did with 6 months [14:15:55 CET] <Compn> thats how patch review works, all ass. [14:17:20 CET] <Compn> i think all other devs here respected michaelni's wishes not to be leader. you might want to rethink your position. [14:17:39 CET] <Compn> not that going with the crowd is required. [14:18:21 CET] <wm4> it's not that I'm not respecting his wish [14:18:46 CET] <wm4> but he still holds all the infrastructure, and does things like giving out new push rights or adding me to the security ML [14:20:22 CET] <Compn> that makes him security admin and git admin, not project leader [14:21:28 CET] <Compn> in my opinion anyhow [14:22:50 CET] <Compn> there also might be an exception for corporate sponsored/authored code [14:23:12 CET] <nevcairiel> only if the exception reads that we never accept it [14:23:19 CET] <nevcairiel> because its usually terrible and horrible and awful [14:23:21 CET] <Compn> for example, vdpau code maintainer might not be so active on our list [14:23:36 CET] <Compn> all the @nvidia copyright in ffmpeg... [14:29:17 CET] <Compn> by exception i mean exception to the time limit. if 2 years was used, probably dont need an exception. [14:33:48 CET] <BtbN> Compn, what's so bad about @nvidia.com authors? The code is still LGPL, someone from nvidia adding stuff to it doesn't change that. [14:33:58 CET] <BtbN> I very much appreciate the work from nvidia on nvenc [14:37:05 CET] <Compn> BtbN : i agree, thats why i suggested an exemption so they could have more time to review. i'm reviewing wm4's patch... [14:37:15 CET] <Compn> BtbN : nevcairiel is the one who said he didnt like corporate code [14:37:39 CET] <BtbN> oh, that's what you mean by exception [14:37:47 CET] <Compn> yea [14:38:28 CET] <Compn> i re-read my original statement and it lacked the proper context... tried to clarify but was unsuccessful :( [14:39:29 CET] <Compn> we americans are under constant word salad attacks... hard to form english anymore with these violations being broadcast all day [14:39:58 CET] <Compn> please forgive my poor english :D [14:45:45 CET] <wm4> salad attacks? [14:47:07 CET] <wm4> I assume mixing encoding and stream copy to the same target file is completely allowed? [14:47:43 CET] <BtbN> Of course, re-encoding video but just copying the audio seeems quite common [14:47:55 CET] <wm4> urgh [14:50:13 CET] <Compn> it causes many problems for vlc and other players however, because mencoder/ffmpeg dont fix timestamps sometimes when people do this [14:51:04 CET] <wm4> no secret that ffmpeg sometimes creates broken files without any indication or warning [14:51:41 CET] <Compn> 'warning, you are reencoding video but copying audio, this could cause problems' ? [14:52:13 CET] <Compn> i would support this message that no one would ever read. [14:52:21 CET] <wm4> that doesn't have to do with that, it's true in general and also streamcopy is fragile by nature [14:52:46 CET] <Compn> why not make streamcopy robust ? [14:56:55 CET] <wm4> Compn: because it's fragile by nature [14:57:16 CET] <Compn> make it unnatural [14:57:26 CET] <Compn> control all the bitstreams. [15:55:01 CET] <wm4> michaelni: I've updated my filter init merge patches, I think there are still some of your cases failing, while others work: https://github.com/wm4/FFmpeg/commits/filter-merge [16:28:35 CET] <nevcairiel> wm4: doesnt the second mux_timebase set in init_output_stream override the one from init_output_stream_encode [16:44:34 CET] <cone-645> ffmpeg 03Rick Kern 07master:70ebc05bce51: lavc/videotoolboxenc: fix symbol linking [16:49:09 CET] <wm4> nevcairiel: forgot to remove that [16:51:08 CET] <wm4> seems like a pretty serious oversight [18:14:43 CET] <wm4> philipl: should cuvid be disabled on osx? (I don't know) [18:27:50 CET] <adeeln_> durandal_1707: I'm still stuck on the probe issue. The difference file has the same size. https://gist.github.com/adl1995/5a454e565c5c053cc5908526d57b1f18 (same as yesterday) [18:31:25 CET] <durandal_1707> give full diff [18:31:39 CET] <durandal_1707> not diff of diff of diff... [18:49:16 CET] <philipl> wm4: I think so. nvidia certainly don't claim to support it, although they say that about cuvid on xp too and that works. [18:49:55 CET] <nevcairiel> noone in their right mind should claim anything works in xp [18:49:57 CET] <philipl> I do know that the call I used to get the device being used for the opengl context is documented to only work on linux/windows, so I assume that would fail before any cuvid functionality could be tested. [18:50:16 CET] <adeeln_> durandal_1707: I've commited the code to a separate branch and given this command: sudo git diff master > work.txt but the output file remains unchanged [18:50:18 CET] <philipl> Sorry, that call is in mpv. [18:50:24 CET] <philipl> In ffmpeg, there is no use of that. [18:50:52 CET] <philipl> So, someone has to try it and see. With the one model of macbook pro that nvidia produce drivers for [18:52:25 CET] <wm4> nevcairiel: ffmpeg works on XP [18:52:49 CET] <nevcairiel> we dont make any claims it works anywhere, we let binary providers figure that out =p [18:52:57 CET] <wm4> philipl: the ffmpeg cuda stuff doesn't even load the right .dylib on osx [18:53:32 CET] <durandal_1707> adeeln_: check output of git log [18:53:54 CET] <philipl> wm4: well then :-) [18:54:37 CET] <philipl> It's most assuredly never been tested. Back when we linked against system libraries it would fail at configure time. Now it will always build, whether it's usable or not [18:58:13 CET] <adeel2> durandal_1707: this is the last one: commit 77bb6835ba752bb9335d208963a53227bbb1bc63 Author: (no author) <(no author)@9553f0bf-9b14-0410-a0b8-cfaf0461ba5b> Date: Wed Dec 20 00:02:47 2000 +0000 New repository initialized by cvs2svn. Originally committed as revision 1 to svn://svn.ffmpeg.org/ffmpeg/trunk [18:59:08 CET] <nevcairiel> we use git, not svn [19:00:05 CET] <durandal_1707> adeel2: whatever you done is wrong [19:00:49 CET] <durandal_1707> adeel2: make proper git clone [19:01:37 CET] <wm4> that's the first commit in the ffmpeg git repo [19:01:39 CET] <wm4> (same hash) [19:03:56 CET] <adeel2> durandal_1707: okay, making a new clone [19:04:19 CET] <durandal_1707> adeel2: what was first log instead? [19:04:31 CET] <adeel2> let me check [19:05:12 CET] <adeel2> commit 7731b0475da706f802c004a10da1e58186509718 Author: Adeel Ahmad <adeelahmad14(a)hotmail.com> Date: Tue Feb 28 23:52:39 2017 +0500 changes [19:05:33 CET] <adeel2> I sent the last log last time [19:07:56 CET] <durandal_1707> and one before that? [19:13:08 CET] <adeel2> durandal_1707: difference of first two commits: https://gist.github.com/adl1995/73b79c4b6bc655f42015f10f16d601b6 let me know if this helps [19:17:55 CET] <atana> michaelni, ping [19:18:42 CET] <atana> what is the next step? should I start testing or more modification is needed [19:19:58 CET] <durandal_1707> adeel2: still bad. try diff of 3 commits [19:25:42 CET] <durandal_1707> adeel2: git diff HEAD^3 iirc [19:30:28 CET] <wm4> adeel2: always use a branch, then you can do "git diff master" [19:31:48 CET] <adeel2> here is a difference of last 3 commits: https://gist.github.com/adl1995/f695c576e7a381779149d89cabbe6bc2f [19:32:04 CET] <adeel2> not sure what 'git diff HEAD^3 iirc' means [19:32:21 CET] <JEEB> and just fork the ffmpeg repo on github and have your own repo to which you can easily link to :P [19:32:32 CET] <JEEB> or gitlab or whatever else, github is just the most used one [19:32:41 CET] <adeel2> wm4: I tried creating a new branch but git diff gave the same output [19:32:58 CET] <JEEB> yes, if you created it after you already had committed some stuff :P [19:33:30 CET] <adeel2> JEEB: oh yeah, I did do that :D [19:33:46 CET] <JEEB> if you are on *nix use gitk to visualize things [19:33:50 CET] <wm4> JEEB: a github fork would actually make it harder tp sync with upstream [19:33:53 CET] <wm4> *to [19:34:10 CET] <JEEB> wm4: having both as remotes, with official videolan thing as "origin" [19:34:15 CET] <wm4> because pulling/fetching would work on your forked repo instead of upstream [19:34:30 CET] <JEEB> esp. now that he has a remote already set [19:35:12 CET] <wm4> I'd say just learn how branches and git fetch works and how commits are "linked" [19:35:34 CET] <wm4> and get some good tool that can visalize the current state of your repo (like gitk or whatever) [19:35:41 CET] <wm4> *visualize [19:36:40 CET] <adeel2> just installed gitk [19:37:32 CET] <durandal_1707> adeel2: link doesnt work for me [19:40:00 CET] <adeel2> durandal_1707: fixed it. Please check: https://gist.github.com/adl1995/ce17fa770dc6229a487f6dfefd40b634 [19:46:48 CET] <durandal_1707> adeel2: better start over in fresh new branch, do not modify master branch it should be same as ffmpeg [19:48:04 CET] <adeel2> durandal_1707: do I create the new branch in seperate new fork? [19:49:13 CET] <durandal_1707> doesnt matter [19:49:29 CET] <durandal_1707> just make sure master is untouched [19:49:59 CET] <adeel2> I already made my previous changes (past few days) in master branch [19:54:29 CET] <durandal_1707> master branch should be kept untouched [19:55:15 CET] <wm4> it's up to you, but especially if you're new with git it's probably less confusing to strictly not touch master, and work in a different branch [19:58:04 CET] <michaelni> hi atana [19:59:43 CET] <adeel2> durandal_1707: here's what I did: 'git checkout -b new_branch' and then 'git diff master > work.txt', the output is: https://gist.github.com/adl1995/7841f0d77e0a9e01c815011430511b24 [20:00:22 CET] <michaelni> atana, testing surely makes sense, more modifications will be needed [20:01:04 CET] <michaelni> but it would be ideal if some testing is done between modifications so we can make sure all modifications improve things [20:18:42 CET] <atana> michaelni, so should I proceed with the dataset we decided upon? [20:19:40 CET] <michaelni> yes [20:29:07 CET] <durandal_1707> adeel2: clear your master branch [20:31:39 CET] <durandal_1707> your master branch have unwanted commits [20:53:02 CET] <J_Darnley> Before clearing anything see if this will get what someone is looking for: git diff origin/master [20:53:16 CET] <J_Darnley> Argh [21:56:44 CET] <llogan> looks like site is down (for me in the US at least), but it appears to be an issue with trac server as well, so probably a networking issue we can do nothing about [22:01:21 CET] <llogan> tracepath makes it to a telepoint ip but nothing beyond that. [22:10:23 CET] <llogan> back now. self-talking man. [22:43:51 CET] Action: Compn high fives llogan [22:45:26 CET] <nevcairiel> trac works for me [22:45:35 CET] <nevcairiel> oh right, back :p [00:00:00 CET] --- Thu Mar 2 2017

1 0

ffmpeg.log.20170301
by burek 02 Mar '17

02 Mar '17

[01:05:19 CET] <arog> hey in nvenc how do you set it up to be lossless? [01:10:14 CET] <arog> its really blurry right now [01:13:23 CET] <arog> is it possible to see all the different options I could set? [01:29:22 CET] <thebombzen_> arog: ffmpeg -h encoder=h264_nvenc [01:29:25 CET] <thebombzen_> that'll list all the options [01:29:30 CET] <arog> thanks [01:29:36 CET] <arog> but tehre is no way to tell if the option was applied correctly [01:29:46 CET] <arog> av_dict_set( &codec_options, "preset", std::to_string(10).c_str(), 0 ); [01:29:46 CET] <thebombzen_> the one you're looking for is -preset:v lossless [01:29:53 CET] <arog> i thought it has to be an int [01:29:58 CET] <thebombzen_> perhaps [01:30:09 CET] <arog> in any case how can i tell if it is lossless [01:30:10 CET] <thebombzen_> I don't know. sometimes ffmpeg.c is smart enough [01:30:23 CET] <furq> a lot of integer options have string mappings [01:30:25 CET] <furq> e.g. vsync [01:30:33 CET] <thebombzen_> so if you're using the CLI tool, maybe. if you're using libavcodec, then maybe [01:31:00 CET] <thebombzen_> using an int is the old method, most of the new options require strings. it's possible that nvenc is using bad ones and it's int mappings [01:31:26 CET] <thebombzen_> the issue is probably the most if you're setting the level. because idk if "-level 4" sets the level to be 4.0 or to be the 5th option on the list [01:31:39 CET] <arog> i never set the level [01:32:02 CET] <thebombzen_> you probably shouldn't unless you know exactly what the restrictions are [01:32:08 CET] <arog> heh [01:32:26 CET] <thebombzen_> but yea. idk if you can use "-preset lossless" or if you have to use -preset 10 [01:32:44 CET] <arog> is it possible to figujre out if my video is lossless [01:49:07 CET] <thebombzen_> one way is to check the bitrate. if it's absurdly high, then it's lossless [01:55:10 CET] <thebombzen_> speaking of nvenc, does anyone here know how nvenc_hevc compares to libx264 with respect to quality per bitrate? [02:00:59 CET] <furq> badly [02:01:10 CET] <furq> i've not tested but that's according to the fine folks in #ffmpeg [02:01:31 CET] <furq> as far as i know it's not really much better than nvenc h264, it's just an hevc bitstream [02:08:52 CET] <thebombzen_> then like [02:08:54 CET] <thebombzen_> what's the point lol [02:10:57 CET] <thebombzen_> so upon futher googling, x264 with -preset veryslow outperforms hevc_nvenc, but hevc_nvenc outperforms x264 using the faster presets (such as -preset medium) [02:11:11 CET] <c3r1c3-Win> To brag that they 'support' HEVC... but at least on the decode side they do, and that does account for something. [02:11:51 CET] <thebombzen_> so apparently it only outperforms it if you use a fast preset [02:12:04 CET] <thebombzen_> so it's better for realtime grabbing b/c [02:12:20 CET] <thebombzen_> b/c it offloads the cpu and performs better anyway [03:27:36 CET] <TikityTik> What's a good audio codec for good compression for mp4s? [03:29:02 CET] <TikityTik> opus? vorbis? [03:38:02 CET] <furq> aac [03:52:19 CET] <TikityTik> Also what is bufsize? How does it affect quality, size, and encoding speed? [04:01:52 CET] <thebombzen_> furq: mp4 supports vorbis [04:02:12 CET] <thebombzen_> techncially it supports opus too, but libavformat doesn't know that yet [04:16:41 CET] <furq> is that actually finalised now [04:40:12 CET] <TikityTik> What is bufsize? How does it affect quality, size, and encoding speed? [04:40:33 CET] <TikityTik> Also if I use -ac 1 to make my audio mono, does the actual audio bitrate get divided by 2? [04:44:42 CET] <thebombzen_> furq: it's on the table of accepted fourccs [04:44:49 CET] <thebombzen_> on the official website I think [04:49:59 CET] <evex> hey dudes [04:50:04 CET] <evex> anybody here? [04:57:09 CET] <TikityTik> yes [04:58:03 CET] <TikityTik> evex: just ask your question [05:03:23 CET] <evex> yes [05:03:33 CET] <evex> ok so I have a folder that have a some 20+ videos [05:03:34 CET] <evex> all mp4 [05:03:42 CET] <evex> and I want to merge all of these together [05:03:46 CET] <evex> I tried the concat [05:04:11 CET] <evex> I tried it with cli input -i 'concat:file.mp4|file.mp4' [05:04:16 CET] <evex> and I tried it with a file [05:04:34 CET] <evex> both produced a video thats out of sync between video and audio [05:04:58 CET] <evex> and sometimes the video just freezes [05:05:17 CET] <evex> I tried the mmcat script found at the ffmpeg.org website [05:05:19 CET] <evex> didn't work [05:05:38 CET] <evex> I tried mp4box, it produced a video that's so messy [05:05:55 CET] <evex> how do I know wether the problem is from my videos or from ffmpeg [05:06:07 CET] <evex> this is how I'm getting the videos [05:06:25 CET] <evex> basically I'm downloading specific parts from a youtube video [05:07:37 CET] <evex> ffmpeg -n -ss 2 -i $(youtube-dl -f mp4 --get-url https://www.youtube.com/watch?v=F9z6LZAasls) -t 10 F9z6LZAasls_1.mp4; [05:07:47 CET] <evex> after downloading vids from youtube [05:07:52 CET] <evex> I'm trying to merge them [05:07:57 CET] <evex> and there happens the issue [05:08:16 CET] <evex> each video of these download is perfectly fine when played alone [05:09:03 CET] <evex> what do you think I'm doing wrong? and what should I do to merge these mp4 files? [05:10:28 CET] <TikityTik> evex: are you also re-encoding the audio with the audio? [05:10:38 CET] <TikityTik> I mean the audio with the video [05:11:32 CET] <evex> not when I'm merging [05:11:36 CET] <TikityTik> evex: Are you only encoding the video? Are you using -c:a copy or -c:v copy? [05:11:50 CET] <evex> yea its all copy [05:12:07 CET] <TikityTik> evex: Usually I find using copy doesn't work for that kind of stuff [05:12:18 CET] <TikityTik> evex: sometimes it even breaks when trimming just 1 video [05:12:30 CET] <TikityTik> There might be a way to go around this, but I don't know it. [05:12:36 CET] <evex> hmm [05:12:48 CET] <TikityTik> evex: Your best bet is to actually specify a video & audio codec for it to fully work [05:12:50 CET] <evex> I'll try to encode the audio with aac and video with h264 [05:12:54 CET] <evex> give me a sec [05:13:42 CET] <TikityTik> But I'm not ffmpeg expert, so there might be a workaround. But I always had issues with copy for editing. [05:15:02 CET] <TikityTik> Also why is it that when I specify -ac 1 for aac encoding, the filesize increases? Shouldn't the file size decrease since there's 1 channel instead of 2? [05:15:25 CET] <evex> I have no idea man [05:19:13 CET] <evex> I'm not sure whats happening but [05:19:39 CET] <evex> ffmpeg -i 'concat:file2.mp4|file1.mp4' -y -c:a aac -c:v libx264 output.mp4 [05:19:50 CET] <evex> produces a file with only one video [05:19:54 CET] <evex> it didn't concat anything [05:23:13 CET] <deneme> hi [05:25:01 CET] <evex> ls *.mp4 | perl -ne 'print "file $_"' > test.test ; ffmpeg -f concat -i test.test -c:a aac -c:v libx264 Movie_Joined.mp4 [05:25:17 CET] <deneme> when i tried to decode a h264 video file, i always get errors [05:25:19 CET] <evex> this is the last command [05:25:21 CET] <deneme> like this. [05:25:22 CET] <deneme> [h264 @ 0000019262FA00A0] Invalid NAL unit size (554406925 > 554). [h264 @ 0000019262FA00A0] Error splitting the input into NAL units. [05:25:28 CET] <evex> it worked but the video got stuck again [05:26:38 CET] <deneme> how can i solve this problem? i'm using ffmpeg 3.2.0 in C [05:26:40 CET] <TikityTik> evex: as far as I know, concatenating is more complicated [05:26:49 CET] <evex> damn [05:27:03 CET] <evex> with iMovie its like 10 sec job [05:27:10 CET] <evex> but I want to automate it [05:27:16 CET] <evex> this really sucks [05:27:33 CET] <TikityTik> evex: You already read https://trac.ffmpeg.org/wiki/Concatenate ? [05:27:47 CET] <evex> yes [05:28:04 CET] <evex> the mmcat script I was talking about earlier is from there [05:28:47 CET] <TikityTik> evex: and all the input files are the same container and same codecs? [05:29:41 CET] <evex> I'm not sure [05:29:48 CET] <evex> let me see if they are [05:30:10 CET] <evex> I'm giving mmcat another try as well [05:30:14 CET] <TikityTik> evex: Check via ffprobe [05:30:30 CET] <evex> ok [05:30:35 CET] <TikityTik> evex: If they are different codecs then you have to use a different method [05:30:44 CET] <Diag> https://www.youtube.com/watch?v=qmfqpOGzOhI [05:32:17 CET] <TikityTik> deneme: Paste your command [05:41:48 CET] <evex> python -c "import os; print ';'.join(['ffprobe -v error -show_entries stream=codec_name -of default=noprint_wrappers=1:nokey=1 '+file for file in os.listdir('.') if file.split('.')[-1] in ['mp4']])" | sh [05:41:51 CET] <evex> I made this command [05:41:58 CET] <evex> all codecs are the same [05:42:03 CET] <evex> aac h264 [05:48:50 CET] <deneme> i'm not using .exe files [05:49:35 CET] <deneme> sws_scale(sws_ctx, (uint8_t const * const *)pFrame->data, pFrame->linesize, 0,pCodecCtx->height, pFrameRGB->data, pFrameRGB->linesize); [07:14:20 CET] <nmschulte> There was a post from July 2016 that said ffserver is being dropped w/ next release, and notice on wiki about it. Is this so, and what is the "next release" this post refers to? [07:15:11 CET] <tab1293> Ive inspected http requests that ffmepgs http input format makes to the requested resource and it seems that the range header always has the trailing dash like Range: 0- [07:16:05 CET] <tab1293> but it will often seek through the file with some offset like Range: 1024- [07:16:20 CET] <tab1293> how should the implementing resource know to end the previous requests? [10:30:42 CET] <krstjns> So I have this problem: leakage when running a bunch of decoders and encoders within a single application (both video and audio) [10:31:44 CET] <krstjns> Running the same thing multiple times provides different memory consumption [10:32:17 CET] <krstjns> sometimes it grows to 2gb, other times 3.5gb [10:33:36 CET] <krstjns> Is this a known problem and are there any ways to go around it? [14:12:55 CET] <JC_Yang> how long does it take to build ffmpeg? with 2G ram and 2 cores? typically [14:14:57 CET] <JC_Yang> numbers for modern hardware are welcome, so that I can roughly estimate it [14:21:11 CET] <DHE> my core i7 (recent, 4 cores with hyperthreading) will do it in 2.5 to 3 minutes. [14:21:56 CET] <DHE> so for you I'd guess 12 to 15 minutes [14:22:18 CET] <BtbN> depends a lot on what you enable [14:22:34 CET] <BtbN> The coverity build with absolutely everything enabled takes a good 40 minutes on a dual core [14:22:48 CET] <BtbN> But the coverity compiler is also slow [14:23:04 CET] <BtbN> but it still doubled in time when we enabled more stuff [14:28:09 CET] <JC_Yang> thank u [15:57:20 CET] <john_rambo> Source file : Video = h.264 /// Audio = Opus ....Want to keep the Video (h.264) and convert the audio to mp3 .....PLease help me with the command [15:58:38 CET] <Diag> Why mp3 [15:58:52 CET] <Diag> Once you go opus you never go black [15:59:05 CET] <john_rambo> My hardware player can play only mp3 Diag [15:59:12 CET] <Diag> Oh [15:59:20 CET] <Diag> Rewrite the hardware [16:00:57 CET] <BtbN> it can play h264... but no aac? [16:01:27 CET] <john_rambo> BtbN, I am going to try that now [16:01:44 CET] <Mavrik> yeah, AAC sounds like a better option :) [16:02:00 CET] <Mavrik> -codec:v copy -codec:a aac -b:a 192k should do the job [16:07:14 CET] <john_rambo> Mavrik, ffmpeg -codec:v copy -codec:a aac -b:a 192k <source file> <output file>....Is this correct ? [16:07:56 CET] <kepstin> john_rambo: put the source file before the output options [16:10:10 CET] <john_rambo> kepstin, $ ffmpeg KK.mkv -codec:v copy -codec:a aac -b:a 192k ~/Desktop/KK.avi [16:10:15 CET] <john_rambo> IS this okay ? [16:10:29 CET] <furq> -i KK.mkv [16:10:33 CET] <furq> also don't use avi if you can avoid it [16:12:33 CET] <john_rambo> furq, https://paste.debian.net/917449/ [16:13:54 CET] <Mavrik> your ffmpeg is old [16:14:02 CET] <Mavrik> and the error describes exactly what to do [17:00:00 CET] <xtina_> g'morning guys. i know you're tired of me peppering the chat w questions everyday -_- [17:00:22 CET] <xtina_> i'm still finding that my audio/video streaming command often results in ALSA buffer overruns within the 1st minute when the script is executed upon boot [17:00:29 CET] <xtina_> but this never happens if I manually execute from SSH [17:00:45 CET] <xtina_> I've turned verbosity on the rec command to max, and have scoured the ffmpeg logs as well [17:01:09 CET] <xtina_> I can't find any sign of a problem. when the audio overruns the ffmpeg logs look 100% healthy, and 'rec' logs tell me nothing [17:01:59 CET] <xtina_> the audio and video stay within 500ms of each other in both successful and broken streams [17:02:53 CET] <xtina_> so it doesn't seem like it's the encoder being slower to start up when I execute from boot? [17:03:05 CET] <xtina_> here's the full logs from a successful manual stream: http://vpaste.net/SDtai [17:03:31 CET] <xtina_> here's an overrun stream from boot, identical commands: http://vpaste.net/MFl0k [17:04:42 CET] <xtina_> does anyone have a clue how I can continue debugging..? thanks in advance [17:40:36 CET] <derek__> I've sent at e-mail to ffmpeg-user-owner(a)ffmpeg.org and it's being moderated . How do I register to #ffmpeg , please ? [17:42:52 CET] <pappi> hello. how can you get the command that was used to encode a video stream? [17:44:17 CET] <pappi> if that's not possible, then how can you rebuild the command using a list of parameters ? [17:47:35 CET] <kepstin> xtina_: the box is probably busy doing a bunch of stuff at boot. Have you tried something as simple as adding a sleep for ~10s or so before actually starting up the encoders? [17:49:41 CET] <LongChair> I am trying to benchmark decoding performance on a device. i have read around and found that one way was to use " ffmpeg -i <file> -f null null - -benchmark", but i'm getting errors when doing this [17:50:06 CET] <LongChair> this is the error i'm getting : [17:50:07 CET] <LongChair> Automatic encoder selection failed for output stream #0:0. Default encoder for format null (codec wrapped_avframe) is probably disabled. Please choose an encoder manually. [17:50:07 CET] <LongChair> Error selecting an encoder for stream 0:0 [17:50:18 CET] <mdavis> You only need one "null" [17:50:27 CET] <mdavis> ffmpeg -i <file> -f null - -benchmark [17:50:40 CET] <LongChair> same error with one null [17:51:16 CET] <LongChair> could there be missing configuration flags ? [17:51:32 CET] <LongChair> cuz i basically specified none (all defaults) [17:51:37 CET] <mdavis> can you do ffmpeg -formats | grep null [17:52:00 CET] <mdavis> It should show a line "E null raw null video" [17:52:12 CET] <LongChair> yep has that [17:53:12 CET] <mdavis> Can you do "ffmpeg -buildconf" and post that to pastebin? [17:53:40 CET] <xtina_> kepstin: that's a good point.. i'll try. feeling stupid. thanks :) [17:54:27 CET] <LongChair> mdavis: http://pastebin.com/iGEkFCVP [17:55:26 CET] <mdavis> "--disable-encoders --enable-encoder=ac3" is your problem [17:55:49 CET] <LongChair> ok so which flags am i supposed to use ? [17:56:08 CET] <mdavis> If you want to use null output, you need to add --enable-encoder=wrapped_avframe [17:56:20 CET] <LongChair> ok lemme try that [17:56:24 CET] <mdavis> when compiling [17:56:34 CET] <mdavis> *configuring, I mean [17:57:01 CET] <LongChair> yep [17:58:20 CET] <mdavis> I usually go the other way. I make huge, bloated, do-everything builds :) [17:59:48 CET] <LongChair> hehe [18:00:06 CET] <LongChair> there is no --enable-all flag :) [18:00:16 CET] <mdavis> --arch=x86_64 --enable-gpl --enable-nonfree --extra-cflags='-pipe -I/usr/include/w32api -I/usr/local/include/cuda' --extra-ldflags=-L/usr/local/lib/cuda --extra-libs=-lstdc++ --enable-sdl2 --enable-fontconfig --enable-libass --enable-libmp3lame --enable-version3 --enable-librtmp --enable-libvorbis --enable-libtheora --enable-gnutls --enable-libfreetype --enable-libopus --enable-libschroedinger --enable-libvpx --enable-libwavpack [18:00:16 CET] <mdavis> --enable-libwebp --enable-libx264 --enable-libx265 --enable-librubberband --enable-libfdk-aac --enable-libvidstab --disable-libxcb --enable-opengl --enable-opencl --enable-libnpp [18:00:37 CET] <mdavis> A/V swiss army knife [18:01:37 CET] <LongChair> yeah i probably should have done something similar, the device i'm building it one is a bit slow though .. so limitting the stuff it builds is good, until you end up building it too many times :) [18:02:59 CET] <mdavis> Limiting it after you've tried a full build and figured out what you need is probably the best way to go [18:04:42 CET] <LongChair> indeed [18:18:39 CET] <LongChair> mdavis: same error even with that option :/ [18:20:12 CET] <mdavis> Then I'm out of ideas. Anyone else here can help? [18:20:40 CET] <mdavis> Are you sure you're using the ffmpeg you just built, and not the one previously installed? [18:21:25 CET] <LongChair> yeah that one shows "configuration: --enable-encoder=wrapped_avframe" [18:21:55 CET] <mdavis> Then idk [18:22:25 CET] <LongChair> thanks for your help :) hopefully someone else will have an idea :) [18:23:36 CET] <xtina_> kepstin: sleeping for a while before starting the stream did seem to eliminate overruns. however in my CPU usage prints I don't see high CPU even if I don't sleep before starting the stream, so it's strange that this helps [18:24:44 CET] <forgon> I fucked up an mkv file while reencoding it and don't know why: http://sprunge.us/CMXd [18:27:38 CET] <forgon> Does anyone know what 'Duplicate element' means? [18:27:53 CET] <LongChair> mdavis: though something is odd in the erro message, it's mentionning the default "encoder", where i'd expect it to use a decoder .. [18:28:08 CET] <LongChair> i just want it to read file & decode [18:28:53 CET] <mdavis> LongChair: Technically, it has to encode to a pseudo-codec to use the null format [18:29:18 CET] <mdavis> I think [18:31:58 CET] <furq> who are these people who only have six minutes to get a problem solved [18:41:04 CET] <timothy> hi, I have an ffmpeg line with -filter_complex "[0:v:0] [0:a:0] [1:v:0] [1:a:0] concat=n=2:v=1:a=1 [v] [a]" -map "[v]" -map "[a]" [18:41:34 CET] <timothy> I need to use h264_vaapi and so I need to set format=nv12,hwupload [18:41:46 CET] <timothy> ofc -vf doesn't work [18:42:36 CET] <xtina_> derek__: you have to subscribe to the ffmpeg mailing list [18:42:48 CET] <xtina_> in order to be notified when people reply to your messages [18:43:05 CET] <xtina_> otherwise i think it still gets approved generally but you won't know unless you check the archives on the site [18:43:12 CET] <xtina_> the ffmpeg mailing list has nothing to do with #ffmpeg irc [18:55:01 CET] <forgon> Can someone explain to me how the 'Duplicate element' error might have resulted from my seek and reencode command? [18:55:20 CET] <forgon> http://sprunge.us/CMXd [19:00:12 CET] <furq> forgon: that should work, but you should probably be using the segment muxer instead of doing all that seeking [19:00:16 CET] <furq> !muxer segment [19:00:16 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_002c-… [19:00:49 CET] <furq> with -segment_times [19:01:36 CET] <forgon> furq: Would you be nice and give me the complete syntax? [19:02:32 CET] <forgon> Where do encoding options go? [19:02:36 CET] <furq> -f segment -segment_times 00:20,10:16,24:33,36:38,51:19,1:06:19 %d.mkv [19:03:14 CET] <forgon> furq: And the encoding just stays the same? [19:03:17 CET] <furq> yeah [19:03:20 CET] <forgon> Is your method faster than seeking? [19:03:27 CET] <furq> yeah [19:03:30 CET] <forgon> My file is lossless, that's why I ask. [19:03:43 CET] <furq> yours is seeking from the start five times [19:03:56 CET] <furq> segment just splits the output so it doesn't seek at all [19:05:06 CET] <furq> that will encode 00:00 to 00:20 and 1:06:19 to eof segments though [19:06:40 CET] <forgon> furq: So 2 seeks still :p [19:06:40 CET] <forgon> let me test your idea. [19:06:49 CET] <forgon> Sadly, my laptop crashes a lot. [19:07:15 CET] <furq> you might need to offset the timestamps if you use that with -ss 00:20 [19:08:49 CET] <forgon> Afaik there is also a negative seek, correct? [19:09:02 CET] <furq> there's -sseof [19:12:11 CET] <forgon> So, the current line is: [19:16:40 CET] <forgon> ffmpeg -i input.mkv -vcodec libx264 -acodec flac -f segment -segment_times 00:20,10:16 \%d.mkv [19:17:03 CET] <forgon> Still figuring out the syntax : [19:18:13 CET] <furq> you shouldn't need to escape that % [19:18:22 CET] <forgon> I use the ghastly fish shell [19:18:29 CET] <furq> oh dear [19:18:40 CET] <forgon> Not that I can't use bash, I wrote almost a hundred scripts in it. [19:18:49 CET] <forgon> But I got too lazy for its quirks. [19:20:08 CET] <forgon> With -segment_times 00:00:01,00:00:02 FFmpeg seeks way beyond these times. [19:20:33 CET] <furq> when encoding? [19:20:59 CET] <forgon> With or without specifying codecs. [19:22:13 CET] <furq> what do you mean by "seeks way beyond" [19:23:42 CET] <forgon> I would hope that after 2 seconds part 2 ennds [19:24:04 CET] <forgon> or part 1, since 0 is the first digit here. [19:24:33 CET] <furq> how long is part 2 [19:24:37 CET] <forgon> Yet instead, my first output file is corrupted. [19:25:54 CET] <forgon> dup= in the progress bar and steadily increasing, 0.mkv contains 'Duplicate elements' and is corrupted. [19:26:38 CET] <forgon> And that should definitely be only a second long and finished. [19:27:08 CET] <furq> sounds like fun [19:28:25 CET] <forgon> Better seek 5 times and wait 3 days :p [19:32:16 CET] <forgon> A penance for noobness to the great FFmpeg creators :| [19:39:57 CET] <LongChair1> so i'm trying to bench some specific hw decoder that i have implemented. i will use "ffmpeg -c:v <my_codec> -i <file> -an -f null - -benchmark. [19:40:44 CET] <LongChair1> that starts fine and will start the decoding process, but upon first frame decoded i'm getting this error message : Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto_scaler_0' [19:41:13 CET] <LongChair1> my hw decoder uses a specific pixel format as frame will hold some platform specific info. [19:41:54 CET] <LongChair1> would anyone have a clue on what could be missing or why is it trying to use autoscaler when the filter is set to null ? [19:43:00 CET] <klaxa> interesting, sadly i have no idea what could be wrong [19:44:35 CET] <Duality> i am using -crf 0 to stream losless h264 but on the other side i see that single pixels are spread out over multple any ideas why this could be ? [19:45:11 CET] <kepstin> Duality: does it only happen with bright colors (red, blue)? [19:45:49 CET] <Duality> kepstin: i can do a quick test, i see it happen with blue for sure [19:46:07 CET] <kepstin> Duality: if so, the issue is that the image is being downsampled to yuv420, you might want to explicitly specify -pix_fmt yuv444p or if you have an rgb source, consider using libx264rgb. [19:46:41 CET] <kepstin> if your original source is already yuv420p well, it's losslessly encoding a source that already has this issue... [19:46:47 CET] <Duality> i am currently using -pix_fmt yuv420p [19:47:02 CET] <kepstin> Duality: yep, that would do it [19:47:25 CET] <Duality> the original source is rgb data [19:47:49 CET] <jkqxz> LongChair1: Hardware pixel format setup is tricky, because ffmpeg always makes a filter graph there and your frames have to pass through it. If you have hwcontext support then you can generally push it into doing the right thing with the hw* filters. If you don't you may need to hack ffmpeg. [19:49:55 CET] <jkqxz> (This will hopefully become much easier soon for hwcontext when lazy filter/output setup gets merged from libav, but I don't know whether that will help your case.) [20:01:11 CET] <Duality> my command now looks like this [20:01:14 CET] <Duality> http://pastebin.com/neW3rmx6 [20:01:35 CET] <Duality> but pixels are still spreadout [20:03:22 CET] <Duality> when i change libx264 to libx264 it throws an assertion namely: Assertion `cost >= 0' failed. [20:03:26 CET] <kepstin> but like I said, you might want to try libx264rgb so it's using rgb from end to end [20:03:39 CET] <Duality> libx264rgb * [20:04:17 CET] <kepstin> Duality: again, complete command line and full console output please... [20:04:24 CET] <Duality> yea sorry :) [20:07:12 CET] <Duality> http://pastebin.com/qe7a0ePc [20:07:16 CET] <Duality> is the full output [20:07:33 CET] <Duality> (sorry toke me a bit to figure out that you actually wanted the output logs too [20:08:43 CET] <llogan> it's mandatory [20:09:08 CET] <Duality> yea no exuse sorry again :D [20:11:31 CET] <klaxa> i have never seen that error [20:14:57 CET] <llogan> i can't duplciate the issue [20:15:03 CET] <Duality> :( [20:15:26 CET] <Duality> it's version 3.2.2 [20:15:33 CET] <LongChair1> jkqxz: well that's not 100% clear but thanks :) [20:15:43 CET] <LongChair1> i suppose i'll have to find a workaround :) [20:15:48 CET] <llogan> update your old linked x264 and ffmpeg. users are recommended to use git master branch [20:16:33 CET] <jkqxz> LongChair1: What is your pixel format? [20:16:51 CET] <Duality> llogan: me ? [20:17:48 CET] <LongChair1> it's is not existing inside ffmpeg master. but basically decoder will make avframes with a struct in data[3] that struct holds information for dmabuf stuff [20:18:17 CET] <LongChair1> i use it with mpv for opengl/dmabuf or drm/dmabuf [20:18:33 CET] <jkqxz> Right. I strongly recommend that you make a hwcontext implementation for it. [20:18:52 CET] <llogan> Duality: yes [20:19:12 CET] <LongChair1> jkqxz: ok, i'll have to dig what this means in ffmpeg code [20:25:52 CET] <llogan> Duality: you can get a binary here https://johnvansickle.com/ffmpeg/ [20:26:50 CET] <Duality> llogan: building it right now :) [20:26:53 CET] <relaxed> Duality: also, use -framerate 1000 instead of -r 1000 [20:27:25 CET] <llogan> and -video_size instead of -s [20:28:52 CET] <Duality> are they different ? [20:29:16 CET] <Duality> of does using -video_size make sure that it's video size meant ? [20:30:39 CET] <llogan> IIRC, -r and -framerate are different. at least for image demuxer and some input devices. i never looked into if -video_size is anything different, but it's in the rawvideo demuxer docs [20:45:23 CET] <Duality> llogan: i tried a newer version that was avialable same issue, now i am going to try the binary [20:47:26 CET] <Duality> binary work :) [20:48:39 CET] <Duality> and the pixels are nice now [20:48:49 CET] <Duality> i do see something else though [20:49:21 CET] <Duality> sometimes it flashes a green frame with white square in it. and i am not sending it any ideas what it could be ? [20:57:41 CET] <llogan> hard to say. does the input have the same thing? [21:03:42 CET] <Duality> seems that the archive on the link you gave me didn't include a ffplay :S [21:05:40 CET] <Duality> but i have one now :) [21:09:27 CET] <Duality> no the input does not [21:09:33 CET] <Duality> have that issue [21:12:01 CET] <Duality> could it be the fact that i am streaming over a wifi connection that does something with the udp data ? or does ffmpeg check if the data is valid? [21:14:14 CET] <llogan> Duality: if you output to a local file does it have the same issue? [21:14:51 CET] <Duality> llogan: i streamt it myself locally and it didn't show that issue [21:16:41 CET] <llogan> if it's a network induced issue than I have no idea. not an area i have any interest in. [21:17:01 CET] <Duality> llogan: it doesn't show when saving to file either [21:17:03 CET] <Duality> :) [21:17:55 CET] <Duality> yea could be something weird, but i am so happy that i atleast got it working all the way to playing things remotely [21:18:15 CET] <Duality> thanks to you llogan and kepstin :) you guys are awesome :) [21:32:05 CET] <Duality> llogan: never mind the problem isn't the network or any data parsing, the problem is that the target device is a really slow arm board :D [21:37:55 CET] <chandoo> hi [21:38:17 CET] <chandoo> i am on windows, how to write ffmpeg code in multiple lines [21:38:32 CET] <chandoo> \ is not working in windows [21:39:41 CET] <BtbN> Install a proper shell [21:40:19 CET] <chandoo> BtbN, i didn't get you [21:40:26 CET] <chandoo> you mean power shell? [21:40:43 CET] <BtbN> Whatever you prefer [21:47:27 CET] <derek__> xtina_ Thank you for your reply I have now subscribed to ffmpeg-user(a)ffmpeg.org and resent my e-mail [22:03:31 CET] <chandoo> hi [22:03:45 CET] <chandoo> i am displaying all my cameras in single window [22:05:21 CET] <chandoo> i have only 5 cameras , but the empty space is flickering a lot, how to make it one color constant say blue [22:05:59 CET] <llogan> add the "color" source filter [22:06:24 CET] <llogan> color=c=blue:s=640x360:r=ntsc [22:07:08 CET] <chandoo> this is my cams output [22:07:19 CET] <chandoo> filter complex code [22:07:52 CET] <chandoo> https://paste.fedoraproject.org/paste/zgRSLU8MzPtpGM0qAtV8ol5M1UNdIGYhyRLiv… [22:08:41 CET] <llogan> use color instead of nullsrc [22:09:04 CET] <llogan> you can use vstack and hstack instead of overlay. [22:09:14 CET] <chandoo> -filter_complex "nullsrc=size=920x480 [base] |||| -filter_complex "color=c=blue=size=920x480 [base] [22:09:16 CET] <chandoo> like that [22:09:44 CET] <llogan> sure [22:10:44 CET] <chandoo> didn't work [22:11:01 CET] <llogan> "didn't work" is a very common error. [22:12:31 CET] <chandoo> https://paste.fedoraproject.org/paste/OfUKGhh2mXmPWKxFFg7Sel5M1UNdIGYhyRLiv… [22:12:59 CET] <llogan> blue=size to blue:size [22:14:14 CET] <chandoo> :) it worked [22:14:16 CET] <chandoo> cool [22:14:18 CET] <chandoo> thanks [22:15:06 CET] <llogan> but i would just use *stack filters and add another 320x240 sized blue color as the filler [22:16:25 CET] <llogan> something like "color=s=320x240:r=25:c=blue[blue];[0:v][1:v][2:v]hstack[top];[3:v][4:v][blue]hstack[bottom];[top][bottom]vstack" [22:16:26 CET] <chandoo> actually i got this code some where and i modified it to include the 5 cameras [22:17:20 CET] <chandoo> woow [22:17:29 CET] <chandoo> this is short form [22:17:46 CET] <llogan> easier. and probably faster. [22:18:03 CET] <chandoo> so no need to bother saying where to start and where to end hstack will take care of it right? [22:18:30 CET] <chandoo> yes my laptop is diying to parse the ffmpeg command [22:18:38 CET] Action: chandoo modifying the code [22:18:42 CET] <llogan> i forgot the "inputs" option for *stack (default is 2). [22:19:12 CET] <llogan> see *stack shortest option if you want to force termination when the shortest input terminates (default false) [22:19:16 CET] <chandoo> i have all 5 inputs with -i xxxx -i xxx 5 times [22:22:06 CET] <chandoo> okay [22:22:10 CET] <chandoo> i have this error [22:22:11 CET] <chandoo> [AVFilterGraph @ 03736160] Too many inputs specified for the "hstack" filter. [22:22:11 CET] <chandoo> Error initializing complex filters. [22:22:11 CET] <chandoo> Invalid argument [22:22:23 CET] <chandoo> okay i will check that out [22:23:16 CET] <chandoo> when i run i have lot of errors and there is significant delay in what is happening outside and what i see in the frames [22:23:17 CET] <chandoo> https://paste.fedoraproject.org/paste/quujatyrqXzMVf6El1DxIl5M1UNdIGYhyRLiv… [22:31:40 CET] <k92> Hi everyone, have any try -pass 2 on libvpx-vp9 ? If I remove -pass 2, it work, but if turn it on, it show this: [22:31:50 CET] <k92> [libvpx-vp9 @ 0x55825f1e5a20] v1.6.1 [libvpx-vp9 @ 0x55825f1e5a20] Failed to initialize encoder: Invalid parameter [libvpx-vp9 @ 0x55825f1e5a20] Additional information: rc_twopass_stats_in.buf not set. Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> vp9 (libvpx-vp9)) Stream #0:1 -> #0:1 (truehd (native) -> opus (libopus)) Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, w [22:35:01 CET] <kepstin> k92: have you already run it with -pass 1 to generate the stats file? [22:36:02 CET] <k92> :l no, how to do that @kepstin, please show me ? [22:36:19 CET] <kepstin> run the same command but with '1' instead of '2' [22:36:50 CET] <kepstin> when you do a two-pass encode, you have to run the command twice, first with the option "-pass 1" to generate statistics, then again with the option "-pass 2" to use them. [22:37:08 CET] <k92> wow :D [22:37:27 CET] <k92> but I didn't catch that from docs, am I missing it some where? [22:38:06 CET] <kepstin> k92: it's basically "common knowledge", that's how 2-pass encoding works in all codecs. [22:39:09 CET] <k92> haha, I just switch from handbrake to ffmpeg cli, handbrake auto run 2 times, I've no idea [22:39:25 CET] <kepstin> k92: that said, the description for -pass in https://www.ffmpeg.org/ffmpeg.html#Video-Options does give examples and says how it works [22:39:53 CET] <kepstin> sort of, anyways [22:40:48 CET] <k92> thanks you kepstin, save my day :) [22:43:40 CET] <k92> should have add docs "when you do a two-pass encode, you have to run the command twice, first with the option "-pass 1" to generate statistics, then again with the option "-pass 2" to use them.", much clear than right now [22:45:14 CET] <kepstin> k92: the existing doc that I linked is pretty close to that, actually... [22:45:32 CET] <kepstin> "Select the pass number (1 or 2). It is used to do two-pass video encoding. The statistics of the video are recorded in the first pass into a log file (see also the option -passlogfile), and in the second pass that log file is used to generate the video at the exact requested bitrate." [22:47:21 CET] <k92> I guess it on me, my head still wrap around handbrake way [22:47:37 CET] <k92> anw thank you again :D [23:32:37 CET] <RossW> quiet time in channel ffmpeg? Or is everyone just waiting for the fresh meat to say something stoopid? [23:36:05 CET] <DHE> no preference. nice to have downtime while I eat [23:36:29 CET] <RossW> Sounds fair :) [23:37:26 CET] <RossW> When you've finished eating, perhaps you can talk me down from my frustration? I'm trying to use ffmpeg without fully understanding (well, barely understanding at all) how it works. [23:38:40 CET] <RossW> I've got a large number of still frames, which need to be pulled together into a video. This works. They have to be stills, because depending on the need at the time, I may need all frames, or every 2nd or 5th or 10th. I may need them between only two particular times, etc. [23:39:30 CET] <RossW> I am also wanting to overlay a watermark, which is fine. I've got all that working, but now I've had a request ... to add a timestamp to the video. [23:40:25 CET] <RossW> and this is the one that's driving me nuts. I'm getting close to the conclusion that I have no option but to make an intermediate stage: one to convert the stills to a video, then one to add the overlays. [23:40:49 CET] <llogan> see select filter for choosing every n image. see overlay filter for overlay. see drawtext filter for timestamp. [23:42:23 CET] <RossW> The every n image isn't completely easy, because it's not necessarily a linearly ordered list of files, so I'm getting the ones I need, then piping them to ffmpeg with -f image2pipe [23:42:33 CET] <llogan> ah, ok. [23:43:14 CET] <RossW> overlay is working with -filter_complex and that seems fine. I can locate the watermark where I need it (that varies too) [23:43:48 CET] <RossW> drawtext filter seems not to want to co-exist with filter_complex. That, or my ffmpeg foo simply isn't up to working out the right incantation. [23:44:15 CET] <RossW> It can't apply to the input (because it's still frames), and it won't apply to the output (presumably because of the filter_complex) [23:46:47 CET] <llogan> ffmpeg -i - -i logo.png -filter_complex "[0:v][1:v]overlay,drawtexttext='%{pts\:hms}':x=(w-tw)/2:y=h-(2*lh):fontcolor=white:box=1:boxcolor=black" output [23:47:09 CET] <llogan> should be "drawtext=text" [23:48:20 CET] Action: RossW tries [23:53:23 CET] <RossW> ok, remember I'm coming at this cold and inexperienced with ffmpeg... [23:53:48 CET] <RossW> I have a line that's something like (I'll have to expand some of the variables I'm using to show this) but: [23:56:32 CET] <RossW> | ffmpeg -f image2pipe -r 25 -vcodec mjpeg -i - -i $logo -filter_complex overlay=(main_w*$safe)-overlay_w:(main_h*$safe)-overlay_h -vcodec libx264 -crf $crf $a -b:v ${rate:-200}k -movflags +faststart $output [23:57:26 CET] <RossW> I don't understand the [0:v][1:v] ref, but I'm sure it's critical.. [23:58:29 CET] <RossW> [0:v] is the first stream? Ie, the output from the static pics? [1:v] is the logo? [23:59:36 CET] <llogan> yes [00:00:00 CET] --- Thu Mar 2 2017

1 0