Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

June 2017

1 participants
60 discussions

ffmpeg-devel.log.20170604
by burek 05 Jun '17

05 Jun '17

[00:01:38 CEST] <BtbN> Can someone revert an ban this? That's spam. [00:24:12 CEST] <cone-367> ffmpeg 03Michael Niedermayer 07master:361e0310d95b: avcodec/mlpdec: Check quant_step_size against huff_lsbs [00:24:13 CEST] <cone-367> ffmpeg 03Michael Niedermayer 07master:9221445fa001: avcodec/tiff: Use av_fast_padded_malloc() in tiff_unpack_fax() [00:33:49 CEST] <wm4> michaelni: you ignored my review comments [00:35:23 CEST] <michaelni> wm4, what comment ? what commit/patch do you mean ? [00:37:32 CEST] <wm4> the log filename one [00:39:52 CEST] <michaelni> you said "Mixed opinion about logging that seems dumb, but at least an API user [00:39:53 CEST] <michaelni> can prevent it." and "But please, don't clutter the code with even more image2 exceptions and [00:39:53 CEST] <michaelni> special handling." i didnt add any more special cases than what was already i t he patch and mixed oppinion sounded to me that you dont objeject to te patch [00:40:00 CEST] <michaelni> did i misunderstand you ? [00:41:34 CEST] <wm4> that was a request to remove those exceptions [00:41:58 CEST] <wm4> every time I try to debug the garbage in libavformat/utils.c [00:42:05 CEST] <wm4> you drown in hundreds of such special cases [00:42:17 CEST] <wm4> which make developing this a pain [00:42:22 CEST] <wm4> we don't need more of it, rather less [00:42:32 CEST] <wm4> but I'm sure you don't understand this [05:40:01 CEST] <kevmark> Trying to build a fate test for scale2ref. Since it has two outputs should I be using overlay (or perhaps v/hstack) to combine the two together so it can be framemd5'd? [05:41:26 CEST] <kevmark> It doesn't appear there are any explicit tests for the split filter so I haven't found any examples of testing filters with multiple outputs [05:44:58 CEST] <kevmark> Or I suppose I could send the input that remains unchanged to nullsink because there's no point (I suppose) in testing something that the filter doesn't change [06:36:41 CEST] <philipl> BtbN: perhaps unsurprisingly, the 1030 doesn't have any encode capability - only decode. [11:09:46 CEST] <BtbN> philipl, given that my old gt630 had full encode caps, it's a bit surprising and sad [13:44:05 CEST] <Compn> maybe the trick is [13:45:40 CEST] <Compn> that we convince the distros, especially the older slower 10-year long term ones, to accept static binaries for projects that require the latest and greatest [13:46:40 CEST] <Compn> for example, web browsers, multimedia and whatever other projects that have to have the latest versions [13:47:33 CEST] <Compn> because we cant convince users of these old OS to upgrade, that would be a foul [13:47:46 CEST] <Compn> but we can convince the distros to stop shipping 2 year old versions. [13:55:15 CEST] <DHE> as a user of said 10 year old distro (well, 7) can confirm binary executables and source code both have compatibility issues [13:55:47 CEST] <Compn> even static binaries ? [13:56:36 CEST] <Compn> also, then i'd suggest going further into a distro VM for updated programs [13:56:52 CEST] <Compn> official distro updated vm, specifically for updated projects [13:56:56 CEST] Action: Compn will not rest. [14:04:23 CEST] <cone-027> ffmpeg 03Michael Niedermayer 07master:98256595fae1: avcodec/tiff: Clear deinvert_buf_size on deallocation [14:04:23 CEST] <cone-027> ffmpeg 03Michael Niedermayer 07master:136ce8baa4fc: avcodec/ac3dec_fixed: Fix runtime error: left shift of 419 by 23 places cannot be represented in type 'int' [14:04:23 CEST] <cone-027> ffmpeg 03Michael Niedermayer 07master:faa5a2181df5: avcodec/pafvideo: Check packet size and frame code before ff_reget_buffer() [14:09:43 CEST] <DHE> Compn: static binaries are fine. but glibc symbols and autoconf versions usually ruin my day if simple dependencies don't do it [14:19:44 CEST] <Compn> i'm glad it works then, now to convince distroooooooo [15:09:29 CEST] <cone-027> ffmpeg 03Marton Balint 07master:47c699f7be16: avformat/utils: return impaired streams in av_find_best_stream if only those exist [15:09:30 CEST] <cone-027> ffmpeg 03Marton Balint 07master:880504814a84: avformat/utils: change bitrate to int64_t in av_find_best_stream [16:00:45 CEST] <Compn> https://github.com/leandromoreira/digital_video_introduction [16:03:36 CEST] <Compn> michaelni : they use ffmpeg motion vectors to teach people ^^ [16:04:42 CEST] <Compn> BBB : didnt you make an app to do video analyzing? wonder if these people could use it as well ? [16:04:52 CEST] <Compn> educational purposes [16:13:06 CEST] <bencoh> looks nice :) [16:29:09 CEST] <DHE> <Compn> i'm glad it works then, now to convince distroooooooo # there's limits to static libraries though. for example I'm running folding@home. dynamic linking is mandatory because the GPU driver and version is unknown until runtime [16:36:28 CEST] <Compn> sure [16:38:45 CEST] <cone-027> ffmpeg 03Paul B Mahol 07master:fab1863917b8: avfilter/af_surround: add support for some upmixing of 3.0, 2.1 and 5.1 channel layout [16:53:27 CEST] <cone-027> ffmpeg 03James Almer 07master:3d4026325381: avformat/aacdec: add a custom read_packet function [17:07:01 CEST] <durandal_1707> atomnuker: what happened to your audio denoising filter? [17:19:12 CEST] <atomnuker> a dog ate my code [17:19:53 CEST] <atomnuker> yesterday I realized I had a use for it so I've started to write it now [17:49:31 CEST] <BBB> Compn: I did, yes - but it already exists opensource and web-based for av1 so no need to use mine if its educational only [17:49:59 CEST] <BBB> Compn: and I did read that guide, its quite cool although later on when it talkes about b/p prediction etc. it gets sort of simplistic [17:52:26 CEST] <cone-027> ffmpeg 03Michael Niedermayer 07master:eb5049227033: avcodec/dxv: Check remaining bytes in dxv_decompress_raw() [17:52:27 CEST] <cone-027> ffmpeg 03Michael Niedermayer 07master:29808fff339d: avcodec/hevc_ps: Fix runtime error: index 32 out of bounds for type 'uint8_t [32]' [17:52:28 CEST] <cone-027> ffmpeg 03Michael Niedermayer 07master:e2bbb95d5821: avcodec/wavpack: Fix runtime error: signed integer overflow: 2081021665 - -130689706 cannot be represented in type 'int' [18:44:31 CEST] <durandal_1707> michaelni: how are integer overflows issues important at a:l? [18:46:13 CEST] <michaelni> (signed) integer overflow is not allowed in C [19:02:46 CEST] <rcombs> "not allowed" == "undefined behavior" [19:02:56 CEST] <rcombs> if it was just "implementation-defined" then that'd be fine [19:03:07 CEST] <rcombs> but it's actually UB, which is potentially a mess [19:03:51 CEST] <rcombs> I've seen some fun cases where people assume signed overflow will behave in C as it does on the underlying hardware, and do an `if (<result of math> < 0)` check [19:04:03 CEST] <rcombs> and then the compiler optimizes out the check, because it can never be true unless UB has happened [19:22:36 CEST] <DHE> gcc -fsanitize=thread reports that sws_getContext is not thread safe because you can have a race involving multiple threads invoking ff_sws_rgb2rgb_init()... [19:27:23 CEST] <DHE> I suspect a false positive but still.. [19:45:30 CEST] <atomnuker> I'm not tripping and there is a vts.profile-vc2-low-delay.drc in fate_samples/dirac, right? [21:09:43 CEST] <jamrial> rcombs: can you look at the audiotoolboxdec patchset? [21:10:25 CEST] <jamrial> first and second are important to fix potential memleaks (would also be nice if you can confirm they exist and are fixed by the patches) [22:10:31 CEST] <atomnuker> michaelni: could you upload this sample to the fate samples repo under dirac? https://pars.ee/temp/vts.profile-vc2-low-delay.drc [22:53:46 CEST] <cone-243> ffmpeg 03Paul B Mahol 07master:67162554d458: avfilter/af_afftfilt: fix memory leaks [22:59:52 CEST] <michaelni> atomnuker, done [23:01:54 CEST] <kierank> J_Darnley: ping [23:37:27 CEST] <atomnuker> michaelni: thanks [23:37:47 CEST] <atomnuker> if you had time could you check to see if the patch I sent on the ML to add a test for it is okay [23:42:14 CEST] <cone-243> ffmpeg 03Michael Niedermayer 07master:6019d721d4c1: avutil/softfloat: Fix sign error in and improve documentation of av_int2sf() [23:42:15 CEST] <cone-243> ffmpeg 03Michael Niedermayer 07master:b315a3cf42a1: avcodec/sbrdsp_fixed: Fix assertion failure in sbr_sum_square_c() [23:42:16 CEST] <cone-243> ffmpeg 03Michael Niedermayer 07master:46b865ea9f86: avcodec/qdrw: Fix null pointer dereference [00:00:00 CEST] --- Mon Jun 5 2017

1 0

ffmpeg.log.20170604
by burek 05 Jun '17

05 Jun '17

[00:04:39 CEST] <johnjay> hey furq someone just told they did apt-get install ffmpeg on their debian machine and it worked fine [00:04:56 CEST] <johnjay> did you say something like, it's months out of date? [00:06:24 CEST] <furq> https://packages.debian.org/search?keywords=ffmpeg&searchon=names&suite=all… [00:10:01 CEST] <johnjay> it's all things like libswresample-ffmpeg-dev [00:10:15 CEST] <johnjay> or like php5-ffmpeg [00:10:32 CEST] <furq> what [00:10:50 CEST] <johnjay> wasn't your point that ffmpeg isn't available as a package? [00:11:04 CEST] <johnjay> or like it's oudated? [00:11:09 CEST] <furq> it's not available as a package in jessie [00:11:25 CEST] <johnjay> oh it says jessie-backports [00:11:30 CEST] <furq> yes [00:11:42 CEST] <furq> and the backport apparently breaks every package that depends on ffmpeg that isn't in backports [00:11:55 CEST] <furq> which is another reason you should never run stable [00:21:17 CEST] <johnjay> ah ok he's running backports yes [00:32:58 CEST] <johnjay> he also called mmal "some broadcom thing" used by the rpi fork of chromium [00:37:59 CEST] <furq> well yes it's the broadcom thing that lets you use hwdec on an rpi [00:47:58 CEST] <johnjay> ah so many terms for hardware stuff. vaapi, vdpau, mmal, dri [00:48:37 CEST] <johnjay> by the way i'm trying to get a book on image processing to learn more about it [00:48:50 CEST] <johnjay> do you recommend the one by gonzalez? [00:56:56 CEST] <fallensnow> Hello. Is there a way to output an encoding into another encoding within one instance of ffmpeg? Perhaps via -filter_complex? [00:57:35 CEST] <BtbN> what? [01:01:58 CEST] <furq> what a nice young man [01:17:24 CEST] <kerio> yo dawg i heard u like encodings so we output an encoding into an encoding [01:47:48 CEST] <johnjay> i'm trying to tell if MATE is very popular or not [01:48:06 CEST] <johnjay> i guess any GTK gui will work in both Mate and Gnome3 though? [01:56:52 CEST] <tezogmix> Hi all, what does this message mean and anything to avoid it: "[asf @ 000000000047a620] too long payload" my command was : "ffmpeg -i input.wmv -preset veryfast -crf 15 -c:a aac output.wmv" mediainfo says: "1 video stream = wmv2" + "1 audio steam = wma" - it seems to be converting but that asf payload message keeps appearing nonstop, using latest static build [01:58:55 CEST] <tezogmix> showing ^^ "last message received 150-200 times" [02:18:15 CEST] <fallensnow> BtbN: I'm trying to create screenshots of the output as it encodes. [02:18:59 CEST] <fallensnow> Without having to finish the encode and put it back through another instance of ffmpeg to create screenshots. [04:00:55 CEST] <M6HZ> Hello, I try to use the function "print()" in the "volume" expression [04:03:00 CEST] <M6HZ> This one: ffmpeg -stream_loop -1 -i path/file -af volume=volume='print(10)' -c:a libopus -f ogg - [04:03:06 CEST] <M6HZ> Seems to work fine [04:04:59 CEST] <M6HZ> But this one: ffmpeg -stream_loop -1 -i path/file -af volume=volume='print(10, 8)' -c:a libopus -f ogg - doesn't [04:05:30 CEST] <M6HZ> according to the man page: [04:05:48 CEST] <M6HZ> print(t, l) Prints t with loglevel l [04:06:55 CEST] <M6HZ> loglevel is a string or a number containing one of the following values: [...] fatal, 8 [...] [04:07:26 CEST] <M6HZ> I have tried with both values: 8 and fatal [04:08:17 CEST] <M6HZ> But I got those messages: [04:08:45 CEST] <M6HZ> Press [q] to stop, [?] for help [04:08:45 CEST] <M6HZ> [Parsed_volume_0 @ 0x55c76224f900] [Eval @ 0x7fffa7929690] Missing ')' or too many args in 'print(10' [04:08:45 CEST] <M6HZ> [Parsed_volume_0 @ 0x55c76224f900] Error when evaluating the volume expression 'print(10' [04:08:45 CEST] <M6HZ> [AVFilterGraph @ 0x55c762250140] Error initializing filter 'volume' with args 'volume=print(10' [04:08:45 CEST] <M6HZ> Error reinitializing filters! [04:08:46 CEST] <M6HZ> Failed to inject frame into filter network: Invalid argument [04:08:48 CEST] <M6HZ> Error while processing the decoded data for stream #0:0 [04:08:50 CEST] <M6HZ> Conversion failed! [04:09:07 CEST] <M6HZ> Do you know why ? [04:09:14 CEST] <furq> firstly, don't paste that many lines into irc [04:09:21 CEST] <furq> secondly, replace , with \, [04:15:27 CEST] <M6HZ> furq, Thanks you ! ) [04:17:17 CEST] <M6HZ> furq, do I have to escape the , because of my shell ? [04:19:28 CEST] <M6HZ> or is the reason is intrinsically linked with the operation of ffmpeg? [04:36:51 CEST] <M6HZ> furq, ok I found the response in the man [04:37:17 CEST] <M6HZ> > Notes on filtergraph escaping [04:37:52 CEST] <M6HZ> "(note that in addition to the "\'" escaping special characters, also "," needs to be escaped)." [06:12:22 CEST] <johnjay> hey furq when you said i could install debian directly on the pi [06:12:38 CEST] <johnjay> you mean they release armhf images, or I need to generate the image myself once the new stable is released? [06:40:48 CEST] <furq> didn't i already link the script [09:42:34 CEST] <johnjay> oh yeah you did [09:45:09 CEST] <johnjay> ah it's in the other browser [09:45:16 CEST] <johnjay> i switched to epiphany since it's less of a memory hog [09:47:09 CEST] <johnjay> is emdebian officially part of debian? [09:48:36 CEST] <johnjay> although wait i can just add testing repo to my sources.list right? [09:48:43 CEST] <johnjay> wouldn't that be faster? [09:48:50 CEST] <johnjay> i guess it would still be raspbian though [10:15:48 CEST] <johnjay> furq: i can't install the cross compile toolchain [10:15:59 CEST] <johnjay> crossbuild-essential-armhf : Depends: g++-arm-linux-gnueabihf (>= 4.9.1-1) but it is not going to be installed [11:59:51 CEST] <hendry> when I use ffmpeg on a MP4, to process it for the Web, I noticed massive space savings: https://natalian.org/2017/06/04/Ninety_percent_space_savings/ [12:00:13 CEST] <hendry> is it compression that provides the space savings ? [12:00:57 CEST] <hendry> Or is it the codec? Or is it the drop in bit rate? tbh I can't really tell difference between original and transcoded [12:01:06 CEST] <hendry> but i am keen to better understand what is happening [12:02:12 CEST] <BtbN> your camera just uses an incredibly high bitrate, that's all. [12:02:51 CEST] <hendry> going from a high to low bitrate... what is happening there? just throwing out crap? or some sort of compression? [12:03:13 CEST] <BtbN> I'd guess the camera just has some crappy hardware encoder [12:03:21 CEST] <BtbN> and to make it feasible, they throw bitrate at it [12:04:52 CEST] <hendry> BtbN: ok, so in the process (what is this called?) it just sorts out the bitrate for what it should be without loss ? [12:05:14 CEST] <BtbN> every re-encoding inevitably reduces the quality [12:05:35 CEST] <BtbN> unless you do a lossless encode, but that's not going to happen with 3Mbps [12:05:35 CEST] <hendry> ok, so always lossy, but tbh i can't see the difference at playback with my eyes [12:06:02 CEST] <BtbN> 3Mbps is quite small for 1080p, you usually aim for 5-10 [12:06:08 CEST] <hendry> ok so the process is called "re-encoding" ... just want to get that out the way [12:06:44 CEST] <hendry> ok 3037 kb/s is 3Mbps right [12:07:06 CEST] <hendry> why didn't re-encode to 5-10 by default ? [12:07:12 CEST] <BtbN> Because you told it to? [12:08:37 CEST] <hendry> where did i say that? https://s.natalian.org/2017-06-04/htmlvideo.log [12:08:46 CEST] <hendry> ffmpeg -y -i MVI_4827.MP4 -movflags +faststart -pix_fmt yuv420p -c:v libx264 -vprofile high444 -acodec aac -strict experimental 2017-06-03/MVI_4827.mp4 [12:09:01 CEST] <hendry> +faststart iiuc is to get Web video working i think [12:11:05 CEST] <BtbN> it moved the moov atom to the front of the file, so it can be played faster, hence the name [12:11:20 CEST] <BtbN> And you're not specifying a bitrate or quality, so the bad defaults will be used, you should change that. [12:11:28 CEST] <BtbN> Also, high444 is not supported by a lot of browsers [12:11:38 CEST] <BtbN> And -strict experimental is entirely unneccesary [12:11:49 CEST] <BtbN> Unless you are using a very ancient version of ffmpeg. [12:11:53 CEST] <BtbN> Which you should fix [12:12:25 CEST] <dmko> this is more a shell question I guess, but I have a bunch of processing that ends up with a single line ffmpeg command. when I echo it out and enter it manually, it works.. but when I run it as is, it fails [12:12:33 CEST] <dmko> any tips? [12:15:44 CEST] <dmko> ok nm threw it all in an eval and now it works :D [12:16:26 CEST] <hendry> BtbN: so what are good defaults? -b:v 5000k ? [12:16:37 CEST] <hendry> BtbN: why does ffmpeg have bad defaults? [12:18:10 CEST] <hendry> high444 seems to work on my iPhone & on my desktop Chrome nicely. What's a better default? high ? [12:29:52 CEST] <furq> you're specifying -pix_fmt yuv420p and -profile high444 [12:30:08 CEST] <furq> idk which of those overrides which, but i assume you're getting 4:2:0 [12:30:45 CEST] <furq> maybe with an incorrect profile flag, but that probably doesn't really matter [12:33:02 CEST] <hendry> oh that profile dictates pix_fmt?? i'd happily remove pix_fmt switch from my script to make things easier .. [12:34:11 CEST] <furq> just remove the profile switch [12:34:14 CEST] <furq> it's autodetected anyway [12:36:27 CEST] <hendry> furq: auto-detected? surely you want your output to be a high profile from the camera source? [12:42:43 CEST] <hendry> what's a good bitrate for 4k h264 video incidentally? 5-10 was mentioned for 1080p by BtbN [12:43:02 CEST] <BtbN> 35-50 [12:43:11 CEST] <BtbN> depends on the content obviously [12:43:17 CEST] <Baumfaust> hi [12:43:24 CEST] <BtbN> if possible, you should set a constant quality, and not a constant bitrate [12:44:28 CEST] <hendry> BtbN: yes, I understand variable bit rate is what happens right, depending on the scene etc etc [12:44:33 CEST] <Baumfaust> i want to extrat every minute a frame from a video, starting at minute 19:52 [12:44:35 CEST] <Baumfaust> ffmpeg -i dragon.mp4 -ss '00:19:52' -vf fps=1/60 img%03d.jpg [12:44:39 CEST] <Baumfaust> why does this not work? [12:44:53 CEST] <BtbN> well, if you set a constant bitrate, that's what x264 will do [12:46:06 CEST] <hendry> Baumfaust: i use something like ffmpeg -ss 00:01:00 -i /tmp/scrubbar.mp4 -vsync vfr -vf fps=1/60 -s ${thWidth}x${thHeight} -f image2 -an -y "/tmp/%04d.jpg" [12:47:04 CEST] <hendry> BtbN: how do express a "constant quality" ? [12:47:24 CEST] <Baumfaust> hendry, ah -ss must be at front, it works now [12:47:30 CEST] <hendry> BtbN: is it true what furq was saying, I don't need to specify a profile? I thought that was an important part of re-encoding [12:47:30 CEST] <Baumfaust> but its veeeeery slow [12:48:06 CEST] <hendry> Baumfaust: my scrubbar.mp4 is downscaled to make the process quicker iirc [12:48:30 CEST] <Baumfaust> i will try [12:49:09 CEST] <ChocolateArmpits> hendry, using -crf [12:49:23 CEST] <BtbN> -qp [12:49:32 CEST] <DHE> constant bitrate is more for streaming over the internet where there are bitrate constraints [12:50:14 CEST] <furq> qp isn't constant quality [12:53:14 CEST] <BtbN> it is, in theory even stricter than crf. But for real world crf is usually more convenient. But it's x264 specific [12:54:49 CEST] <DHE> crf tries to aim for constant visual quality. you give a qp-like number, but high motion scenes tend to nudge it up. [12:54:52 CEST] <furq> i mean i guess it is in practice [12:55:08 CEST] <furq> but crf is specifically supposed to be constant perceived quality [12:55:24 CEST] <BtbN> The visual quality of -crf 18 and -qp 18 should be roughly the same [12:55:34 CEST] <furq> yeah, but one will be much bigger [12:55:36 CEST] <BtbN> but the bitrate of crf might be lower [12:55:55 CEST] <hendry> DHE: i don't quite understand that since no transfer is like a reliable 50 kb/s. Surely in practice you always want a video with a variable bitrate, to increase the chances of scenes looking decent, [12:56:06 CEST] <furq> yes [12:56:09 CEST] <furq> that's what both crf and qp do [12:56:45 CEST] <furq> x264 doesn't even have a true cbr mode [12:56:52 CEST] <furq> on account of it's basically useless [12:57:27 CEST] <furq> i'm not sure i could even name a lossy codec that has a true cbr mode [12:57:34 CEST] <furq> even cbr mp3s have the bit reservoir [12:57:56 CEST] <BtbN> aac I guess [12:58:06 CEST] <BtbN> pretty sure libfdk is strict cbr [13:00:44 CEST] <hendry> i don't like the idea of twiddling the bit rate, when i just want good quality in fast scenese as well as fairly static scenes in videos. [13:00:53 CEST] <furq> well then don't [13:01:01 CEST] <furq> i didn't see anyone recommend doing that [13:01:36 CEST] <hendry> furq: oops, might have got confused between cbr and crf [13:02:32 CEST] <furq> just use -crf 20 -tune film -preset veryslow [13:02:42 CEST] <furq> that's what i use for more or less everything [13:05:01 CEST] <hendry> back to profile... i needn't set it for an output? really? [13:05:07 CEST] <furq> no [13:05:27 CEST] <BtbN> isn't the film tune for old film grain or something? [13:05:29 CEST] <furq> unless your device doesn't support higher profiles [13:05:45 CEST] <furq> profile is only really useful if you want to automatically disable features [13:06:03 CEST] <furq> otherwise it'll just use whatever's required by your other encoding settings [13:06:14 CEST] <hendry> furq: i thought of setting a higher profile as enabling cool features [13:06:16 CEST] <furq> BtbN: it biases towards fine detail retention [13:06:28 CEST] <furq> -tune grain does the same thing but more [13:06:35 CEST] <hendry> furq: my devices seem to support high444 and i only care about my devices ;) [13:06:45 CEST] <BtbN> you don't have a 444 input... [13:07:07 CEST] <furq> well yeah that'll be autoselected if you use -pix_fmt yuv444p, and that will be autoselected if your input is yuv444p [13:07:19 CEST] <furq> so again, it's best to just leave that alone unless you need to set it lower [13:07:27 CEST] <hendry> BtbN: i see, so it's only useful for dropping down ? i.e. " disable features"? [13:07:35 CEST] <furq> yeah [13:08:10 CEST] <hendry> furq: i'm hoping to omit `-pix_fmt yuv420p` ... is that safe to do? https://github.com/kaihendry/recordmydesktop2.0/blob/master/htmlvideo#L38 [13:08:15 CEST] <furq> yeah [13:08:19 CEST] <furq> like i said it'll just pick whatever your input is [13:08:29 CEST] <furq> or yuv444p if your input is rgb, which it isn't [13:09:20 CEST] <hendry> ok, updated https://github.com/kaihendry/recordmydesktop2.0/blob/master/htmlvideo#L36 ... hopefully this is all I need for my camera -> video re-encoding to the Web job [13:09:37 CEST] <furq> if you do care about web compatibility then -pix_fmt yuv420p is probably a good idea [13:09:45 CEST] <furq> not many browsers support anything else [13:09:57 CEST] <furq> i'm not sure if any do for h264 [13:09:58 CEST] <DHE> or hardware players for that matter. like some DLNA players [13:10:05 CEST] <furq> yeah and phones [13:10:16 CEST] <furq> hardware decoding generally doesn't work for anything other than 4:2:0 [13:10:23 CEST] <furq> 8-bit 4:2:0, even [13:11:03 CEST] <furq> if "record my desktop" means desktop capture then you'll want to make that configurable really [13:11:19 CEST] <furq> things like small coloured text will turn to shit at 4:2:0 [13:15:39 CEST] <hendry> furq: been using -pix_fmt yuv420p for years without issue ... [13:16:06 CEST] <hendry> ok, going to put -pix_fmt yuv420p back since I care primarily about the Web [13:24:51 CEST] <furq> http://i.imgur.com/JebYP15.png [13:24:57 CEST] <furq> that's 4:2:0 on the right, obviously [16:34:12 CEST] <DHE> I opened a ticket for a (possible) bug, http://trac.ffmpeg.org/ticket/6426 , but wanted to confirm I am not misinterpreting the purpose of av_interleaved_write_frame (as opposed to av_write_frame) [20:42:42 CEST] <Soni> how do I convert raw CDs into FLAC or something? [20:49:55 CEST] <DHE> usually you use something else to rip it to wav or raw PCM first. then ffmpeg [20:51:35 CEST] <kazuma_> your better off using other tools tbh soni [20:51:51 CEST] <kazuma_> eac, with flac.exe as the external encoder [20:52:40 CEST] <kazuma_> it will go out and get all the correct meta data for you and can fill in vorbis tags ect... [20:58:03 CEST] <Soni> I'm on linux, and I have the raw PCMs [20:58:21 CEST] <atomnuker> Soni: if you need to rip and encode you can use this I wrote: https://github.com/atomnuker/cyanrip [22:02:09 CEST] <CptnOblivious> Hello. I'm trying to make gifs with a size less than 8mb. I'm using these lines in ffmpeg but I'm having trouble with the final size of the gifs. Changing the bitrate only changed the final gif size by ~200kb. Can anyone take a look and see what I'm missing. I have a feeling it's in the last line, perhaps I need to set bitrate there? https://pastebin.com/NiajcN42 [22:03:41 CEST] <furq> you might want to use a dedicated gif optimiser like gifsicle [22:09:08 CEST] <CptnOblivious> Thanks furq I'll look into that. I'll see if I can find what gifscicle uses to optimize the gif [22:09:13 CEST] <johnjay> furq: i have ffmpeg 3.2.4-1 now after upgrading to testing. plus mpv is accelerated [22:22:03 CEST] <CptnOblivious> Hmm, after testing the final file is the same size as the original. If anyone else has any suggestions I'd appreciate it [22:27:18 CEST] <kazuma_> out of curiosity, why did you call your ffmpeg variable %FFMPEG_EXE% instead of just %ffmpeg% ? [22:34:54 CEST] <CptnOblivious> oh that's how the line was written. I found those lines in a tutorial. [22:36:53 CEST] <johnjay> ^ this answers a lot of questions about why someone does something [22:39:34 CEST] <CptnOblivious> Yeah I'm a computer noob, especially when it comes to things like this. From what I understand to achieve 8mb I have to change the bitrate but like I said the final size is only changing by 200kb. From about 9.6mb to 9.4mb. I'm also trying to get the fps higher to about 24 since 15 stutters alot on playback [22:40:28 CEST] <BtbN> I don't think you can change the bitrate of a gif, other than via lowering the resolution [22:40:42 CEST] <MrZeus> or the colour palette [22:41:47 CEST] <CptnOblivious> Oh interesting. I was assuming it was pulling the same bitrate from the .mkv during conversion. I guess I can mess around with resolution to see how much that changes the size [22:45:03 CEST] <CptnOblivious> That makes sense now. I thought I was missing something in the third line calling for a bitrate. Lowering the fps from 24 to 15 had a better change in side but I'd rather keep higher frames with hopefully a small reduction in resolution. Thanks for the info everyone [22:45:15 CEST] <CptnOblivious> size* [23:47:03 CEST] <kazuma_> hmm [23:47:12 CEST] <kazuma_> ffmpeg has frozen during an encode [23:47:25 CEST] <kazuma_> but in task manager it's still usin 80% cpu [23:47:45 CEST] <kazuma_> any chance it will start running again, or should i restart it? [23:47:53 CEST] <kazuma_> 40ish mins into a 3hour encode :Z [00:00:00 CEST] --- Mon Jun 5 2017

1 0

ffmpeg-devel.log.20170603
by burek 04 Jun '17

04 Jun '17

[00:11:41 CEST] <cone-651> ffmpeg 03Shivraj Patil 07master:6f35c21659f7: Disable MSA optimization for big endian arch [00:11:42 CEST] <cone-651> ffmpeg 03Michael Niedermayer 07master:14b6adfd4627: avcodec/snowdec: Fix runtime error: signed integer overflow: 1404 * 8388608 cannot be represented in type 'int' [00:11:43 CEST] <cone-651> ffmpeg 03Michael Niedermayer 07master:9faf098163b3: avcodec/aacps: Fix runtime error: left shift of 1073741824 by 1 places cannot be represented in type 'INTFLOAT' (aka 'int') [00:14:15 CEST] <kevmark> is there any way to run tests/fate.sh on a specific commit instead of a branch? make fate seems to just run all the tests but I don't see any way to get an overview of the results [00:14:54 CEST] <kevmark> I essentially want to run fate before and after my commit to see if it causes any tests to fail. [00:15:01 CEST] <nevcairiel> if everything passes thats your result, there isnt really anything much more meaningful - if something fails, it'll stop and you have errors to view [00:15:36 CEST] <kevmark> so a successful run will just spit out exit code 0? [00:52:16 CEST] <divis1969> Hi, I'm trying to understand how the hw accel should be implemented in the ffmpeg. It looks there are 2 ways: to define the accel with REGISTER_HWACCEL or to define it in the ffmpeg_opt.c hwaccels array. What is the correct way? [00:52:54 CEST] <wm4> REGISTER_HWACCEL is to add an AVHWAccel to the internal list in libavcodec [00:53:10 CEST] <wm4> the one in ffmpeg_opt.c is for the ffmpeg.c tool [00:53:24 CEST] <wm4> really depends what you're trying to do [01:05:16 CEST] <divis1969> I need to improve the video decoding on AllWinner A20 to be able to use it with surveilance tools (ex. kerberosio). There is some vdpau_sunxi implementation, but I would prefer to get rid of dependency on X11. And, according to you, it is probably working in ffmpeg only, but kerberosio uses opencv -> libavcodec. [01:06:11 CEST] <divis1969> Some additional info: https://forum.armbian.com/index.php?/topic/4060-hw-accelerated-video-decodi… [01:11:11 CEST] <wm4> well vdpau has no non-x11 support specified [01:11:31 CEST] <wm4> but probably could by posting a proposal on the vdpau mailing list, or something [01:37:11 CEST] <kierank> durandal_1707: fix my mpeg-4 sstp decoder pls ktx [01:46:18 CEST] <cone-651> ffmpeg 03James Almer 07master:2ba896fef7ed: avformat/matroskaenc: also write chapters when output is WebM [02:01:14 CEST] <durandal_1707> kierank: is it on github? [02:01:26 CEST] <kierank> https://github.com/kierank/ffmpeg-sstp [02:01:34 CEST] <kierank> yes but requires mpegvideoctx madness to be resolved [02:02:37 CEST] <kierank> and there's one sample that does stuff that does hybrid dct/rle and that will never fit in mpegvideoctx [03:26:58 CEST] <kevmark> jamrial, are you around? [03:31:15 CEST] <jamrial> yes [03:43:57 CEST] <kevmark> jamrial, thanks for the valgrind test. I'm attempting to boot up an Ubuntu VM now to try and replicate [03:46:23 CEST] <jamrial> kevmark: you can also use gcc address sanitizer for this if that's easier for you [03:46:39 CEST] <jamrial> it also catches the same invalid read [03:54:59 CEST] <DHE> gcc is a lot faster, but I find valgrind to provide better reporting, stack traces, etc [03:56:25 CEST] <kevmark> I believe I could do that by adding --extra-cflags=-fsanitize=kernel-address [03:56:48 CEST] <DHE> kernel-sanitize is for linux. just use -fsanitize=address [03:56:52 CEST] <kevmark> err , yeah [03:57:30 CEST] <kevmark> I'll give both a go if I can. I'm compiling on macOS with clang and I've run into a few issues now [03:58:00 CEST] <DHE> I say use gcc to find possible problems, valgrind to track them down if gcc is giving you problems. [03:58:02 CEST] <kevmark> For instance, clang would gleefully let me compile some invalid C90 stuff whereas gcc on Ubuntu wouldn't [04:03:51 CEST] <kevmark> Adding that line to configure gives me "gcc is unable to create an executable file." error [04:07:09 CEST] <kevmark> Undefined symbols for ___asan_init and some other asan stuff [04:09:03 CEST] <DHE> if you have a custom built gcc installed into /opt or such, you'll need to use -L/opt/gcc-xxx/lib64 or whathaveyou. also make sure your -fsanitize=xx parameter is part of ldflags [04:11:01 CEST] <kevmark> Looks like adding it to --extra-ldflags did the trick for clang masquerading as gcc. [04:19:31 CEST] <kevmark> clang doesn't seem to be catching it. Time to gcc then. [04:19:45 CEST] <kevmark> *time to try [04:25:36 CEST] <jamrial> kevmark: for asan, just configure ffmpeg with --toolchain=gcc-asan or --toolchain=clang-asan [04:26:08 CEST] <kevmark> jamrial, I'll give it a try [04:26:37 CEST] <kevmark> Use that in addition to -fsanitize=address? [04:37:03 CEST] <jamrial> kevmark: no, the toolchain configure option adds the required gcc/clang options [04:37:30 CEST] <kevmark> Okay, I tried it by itself and clang still couldn't find the issue so I'm giving gcc a go now [04:38:52 CEST] <kevmark> Oh wait, I could just be an idiot [04:39:01 CEST] <kevmark> Give me a minute haha [04:48:41 CEST] <kevmark> Yep. That was the problem. I was running the single test (mine) that was guaranteed to work because it wouldn't replicate the behavior. [04:49:18 CEST] <kevmark> scale2ref works just fine, it's when you run the scale filter (single input) that it barfs [13:00:02 CEST] <atomnuker> J_Darnley: what are the speed improvements on the new simple_idct patches? [13:34:17 CEST] <KGB> [13FFV1] 15michaelni closed pull request #66: Definitions (06master...06definitions) 02https://git.io/vHt47 [13:46:47 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vH2Ta [13:46:47 CEST] <KGB> 13FFV1/06master 14ba80af4 15Dave Rice: upgrading to a working group document... [14:04:46 CEST] <BBB> nevcairiel: he doesnt mean theres a code issue [14:04:53 CEST] <BBB> nevcairiel: he means theres a versioning issue in our .v script [14:04:58 CEST] <BBB> nevcairiel: I think hes right TBH [14:04:58 CEST] <nevcairiel> he wants us to fix his package manager [14:05:02 CEST] <BBB> no [14:05:04 CEST] <nevcairiel> yes [14:05:11 CEST] <BBB> the symbol versioning is upstream in our .v file [14:05:13 CEST] <nevcairiel> because his package manager relies on that info [14:05:25 CEST] <nevcairiel> instead of you know, just putting a version number in there [14:05:27 CEST] <BBB> that seems reasonable if we express the information? [14:05:43 CEST] <BBB> if we think the .v file is not trustworthy, why do we have it at all? [14:05:45 CEST] <BBB> then delete it [14:05:47 CEST] <BBB> Im fine with that [14:05:52 CEST] <BBB> but if its there, it should be correct [14:05:58 CEST] <nevcairiel> the .v file is for symbol visibility, we dont use it for versioning [14:06:17 CEST] <BBB> this is like having docs that say we have 1000 of sec vulns and version 1.0 will never be released because we dont support wmv2 yet [14:06:24 CEST] <BBB> we can say we dont really rely on the doc [14:06:25 CEST] <BBB> but its there [14:06:27 CEST] <BBB> and its wrong [14:06:33 CEST] <BBB> so either fix it or delete it [14:06:35 CEST] <BBB> both are fine [14:06:41 CEST] <BBB> but having a broken doc - like a broken .v - is wrong [14:06:43 CEST] <nevcairiel> look at our .v file, it contains one line that says av* [14:06:55 CEST] <BBB> so delete it :) [14:07:03 CEST] <nevcairiel> its required for visibility [14:08:25 CEST] <nevcairiel> without it, the linker wouldnt know which symbols are actually public [14:08:31 CEST] <nevcairiel> like we dont want to export ff* functions [14:08:37 CEST] <BBB> mplayer \o/ [14:09:05 CEST] <BBB> anyway, try to help him along [14:09:14 CEST] <BBB> if the .v should not be trusted, explain that [14:09:32 CEST] <BBB> hes a package manager, he thinks were stupid for not using autotools and supermake [14:09:40 CEST] <BBB> we need to help them [14:09:51 CEST] <nevcairiel> he's a package manager, i think he is stupid for being that =p [14:10:13 CEST] <BBB> J_Darnley: about the idct patches, the first 3 can be ignored, right? I dont think we intend to use the old mmx code for sse2-idct? [14:10:21 CEST] <BBB> nevcairiel: tsk tsk, he means well [14:17:06 CEST] <BtbN> Wouldn't "correctly" using that file also result in applications breaking on every minor bump, because the symbols moved to a diffrent version, even thouhg it would otherwise work fine? [14:18:50 CEST] <nevcairiel> BBB: the key problem is that its not only new functions that appear within the same ABI - if we say extend a struct and an app uses the new field in such a struct, running with an older library still crashes, and no ELF versioning is going to protect you there, its just not compatible in that direction [14:19:11 CEST] <BtbN> Also, if a public function is missing, shouldn't the whole thing fail on startup, because the linker can't find the symbol? [14:19:30 CEST] <nevcairiel> i would think so, but who knows what kind of lazy linking tricks they use [14:19:48 CEST] <nevcairiel> ld has a lazy binding mode i think [14:19:57 CEST] <BtbN> yeah, that case would just crash and burn. And no symbols are even involved [14:21:50 CEST] <wm4> lazy linking bullshit will make it worse, yes [14:22:12 CEST] <BtbN> What I think can be done is include a symbol for every minor version bump [14:22:18 CEST] <wm4> (it's bullshit because apparently it doesn't help that much or makes it worse, but has a huge impact everywhere... shitty "optimization") [14:22:22 CEST] <BtbN> and make an application link against the latest one [14:23:32 CEST] <BtbN> So if an application links against lavc_ver_57_96, and the system only has 57_90, it will refuse to load [14:23:44 CEST] <BtbN> problem with that is, in a lot of cases, such a constellation would work perfectly fine [14:23:56 CEST] <nevcairiel> why would distributions ever have this problem anyway, dont they build everything against the same version anyway [14:24:17 CEST] <BtbN> no idea [14:29:08 CEST] <BBB> also Im not sure you guys are right [14:29:21 CEST] <BBB> I think if you only use the public API as documented, our FW API compat is pretty decent [14:29:35 CEST] <BBB> if you abuse it or do things documented to be bad, youre in for trouble, duh [14:29:49 CEST] <BBB> but a simple video decoder app compiled against 3.0 will work against 3.1 if the major .so is the same [14:30:00 CEST] <BBB> we bump major .so version if thats not the case [14:30:10 CEST] <BBB> and I believe weve been pretty good at doing that [14:30:15 CEST] <nevcairiel> i dont think anyone claimed that this direction would be problematic [14:30:24 CEST] <nevcairiel> that guy on the ML is talking about the other direction [14:30:29 CEST] <BBB> > >Anyway, in general, I recommend not pretending that FFmpeg has ABI [14:30:29 CEST] <BBB> > >compatibility. Especially not across major releases [14:30:40 CEST] <BBB> that suggests its bad in both directions [14:30:52 CEST] <BBB> but I think we agree its ok in the FW direction [14:31:09 CEST] <BBB> and he suggests we bump majors at each major release [14:31:24 CEST] <BBB> I dont think we need to do that unless we actually broke ABI/API (removed/renamed symbols etc.) [14:31:54 CEST] <wm4> why care about ABI [14:33:14 CEST] <wm4> as someone who has an open source project that uses ffmpeg and which is packaged by some distros, I associate nothing but problems with the supposed ABI "compatibility" [14:33:34 CEST] <wm4> and I added a check to my code which exits with an error if the version libs don't match exactly between runtime/compile time [14:54:11 CEST] <Compn> convince the distros ? [14:54:17 CEST] <Compn> they are the ones who want it [14:54:59 CEST] <Compn> and by it i mean 2 year old ffmpeg system lib [14:55:45 CEST] <BtbN> I really think introducing a GLIBC like symbol that prevents running against older ffmpeg libraries, even just for minor bumps [14:56:00 CEST] <BtbN> , might be a good idea. [14:56:11 CEST] <wm4> doesn't glibc just use fine grained symbol versioning [14:56:32 CEST] <BtbN> that's for its backwards compat [14:56:37 CEST] <DHE> sorta. a function might internally be named sscanf@@GLIBC_2.15 [14:56:52 CEST] <DHE> yeah, but they'll still export sscanf@@GLIBC_2.3 for backwards compatibility [14:56:54 CEST] <BtbN> But in the other way, if something is linked against a more recent glibc than the system has, it also has a mechanism [14:57:18 CEST] <BtbN> it exports a symbol for every version bump it ever did. And applications link against the latest one [14:57:25 CEST] <DHE> no, it just shits itself with a missing symbol. those of us on "old" platforms like centos6 see this regularly. [14:57:28 CEST] <BtbN> so an older version won't have that symbol, and startup will fail [14:58:05 CEST] <wm4> (solution: don't use centos) [14:58:28 CEST] <wm4> BtbN: can't glibc do this only because it's the runtime lib? [14:58:36 CEST] <DHE> wm4: a 10 year support cycle is VERY appealing [14:58:51 CEST] <BtbN> I don't see why ffmpeg couldn't do it aswell [14:59:51 CEST] <wm4> DHE: depends on the kind of misery that it's for, I guess [15:03:01 CEST] <nevcairiel> the problem starts when people use such a distro and then still expect to run the latest stuff on it [15:15:06 CEST] <kierank> atomnuker: 40% so far but not fully optimised and not fully correct iirc [15:26:54 CEST] <atomnuker> very nice [15:28:39 CEST] <kierank> I don't like seeing that ugly mmx inline thing in our profiles [16:15:46 CEST] <gh0st__> kierank: what's wrong with mmx? [16:16:00 CEST] <kierank> 2017 is wrong with mmx [16:16:39 CEST] <gh0st__> ah, I see. But why not to keep? code size? [16:18:52 CEST] <wm4> maintenance burden, and the need to deal with emms are good reasons to drop mmx [16:20:41 CEST] <durandal_1707> drop ths mmx [16:20:46 CEST] <gh0st__> I see, what is emm? [17:16:47 CEST] <KGB> [13FFV1] 15JeromeMartinez opened pull request #68: Make Quantization descriptions more coherent (06master...06QuantizationTables) 02https://git.io/vH23k [17:22:21 CEST] <BBB> gh0st__: emms is an instruction that clears the mmx/floating point (x87) state; its basically pointless on x86-64 since nobody uses x87, but since its there you have to clear it anyway, its slow and stupid [17:22:39 CEST] <BBB> gh0st__: mmx is fine if it fits specifically only in mmx regs, but if it fits in xmm, use only xmm and ignore mmx for all you can :) [17:41:52 CEST] <cone-976> ffmpeg 03James Almer 07master:be3809a521fe: x86/aacpsdsp: optimize ff_ps_stereo_interpolate_sse3 [18:16:28 CEST] <Gramner> mmx isn't necessarily fine just because the size of an mmx register is enough to fit your data. padd(u)s*, psub(u)s*, pcmp*, pmax*, pmin*, pavg*, pabs* and psign* (and maybe something else, don't remember) only execute with half throughput in mmx registers compared to xmm registers on modern intel cpus [20:40:30 CEST] <nevcairiel> durandal_1707: do you plan more flexible input to the upmix filter? like 3.0 input to 5.1, or something like that? [20:45:03 CEST] <durandal_1707> nevcairiel: anything that have left and right channels could be upmixed, why? [20:45:41 CEST] <nevcairiel> durandal_1707: but it would overwrite the existing channel then? and just wondering, it would be nice to have it work on any input [20:46:14 CEST] <durandal_1707> thats lot of combinations and code [20:46:31 CEST] <nevcairiel> i guess [20:47:38 CEST] <nevcairiel> could do it a bit flexible and just treat the input as stereo, but if a channel already exists just dont overwrite it [21:15:10 CEST] <durandal_1707> channels need to be overwritten for proper separation [21:15:41 CEST] <durandal_1707> except for center channels [21:16:02 CEST] <durandal_1707> thay can be left unchanged [21:18:17 CEST] <nevcairiel> i suppose it would mostly be 3.0 signals (ie. stereo with center), stereo with lfe, or stereo center and lfe [21:19:48 CEST] <nevcairiel> in any case the existing filter is already pretty good, stereo to 5.1 is what most people have asked me for [21:19:53 CEST] <wm4> lol at all those API and ABI fuckups [21:22:10 CEST] <kierank> durandal_1707: so I have an idea to split mpeg-4 from mpeg2 [21:28:43 CEST] <jamrial> wm4: afaik, codecpar being at the end was because downstream projects were accessing private fields, and when it was introduced above the private line the offsets for said private fields changed and those projects started to crash [21:29:17 CEST] <jamrial> so we compromised, moved it down, and violated our own rules. because downstream projects can't follow them [21:29:42 CEST] <jamrial> you kinda "fixed" it by adding a "from here on, things are public again" marker that made it on 3.3 i think [21:29:56 CEST] <jamrial> which is ugly af but will be gone once we bump [21:30:16 CEST] <nevcairiel> we should start making a bump checklist thing [21:30:20 CEST] <nevcairiel> so many things we still wanted to move [21:30:21 CEST] <jamrial> ^ [21:31:15 CEST] <durandal_1707> kierank: really, how much code change? [21:31:42 CEST] <wm4> we could also move the private fields into an internal struct now, and leave only padding fields to keep current ABI [21:32:13 CEST] <nevcairiel> nah lets just do it all in one go, no reason to break such apps silently [21:32:14 CEST] <jamrial> what's the point? we're not going to branch a new release before we bump [21:32:16 CEST] <jamrial> hopefully [21:32:17 CEST] <wm4> if downstream apps have real reasons to access some of the fields, new APIs can be added, otherwise fuck them [21:32:45 CEST] <BtbN> I don't think anything would break when removing the private fields [21:32:53 CEST] <kierank> durandal_1707: dunno, but only way I can merge my decoder afaik [21:32:54 CEST] <BtbN> Except something does terrible things [21:34:39 CEST] <BtbN> What we could do is move them to a private struct, and embed that private struct at the end of the existing struct. [21:34:44 CEST] <BtbN> So API would break, but ABI won't [21:35:01 CEST] <nevcairiel> we basically already have a plan, so lets just do it at bump time [21:35:49 CEST] <BtbN> 3.4 will most likely be a major bump, won't it? [21:36:01 CEST] <nevcairiel> probably [21:37:09 CEST] <jamrial> i'd rather call it 4.0. major bump, dropped api, so better if we make it obvious [22:15:17 CEST] <jamrial> nevcairiel: can you review the vpcc on mov demuxer patch? [22:15:27 CEST] <jamrial> i basically only read the color info, since the rest can be derived from the bitstream [22:21:39 CEST] <durandal_1707> nevcairiel: do you have 3.0 samples? [22:24:11 CEST] <nevcairiel> i have a 3.1 real content, and 3.0 artificial content [22:26:25 CEST] <durandal_1707> 3.1 should be good, i could just drop lfe and compare [22:28:17 CEST] <nevcairiel> http://files.1f0.de/samples/3.1-st.mkv [22:29:28 CEST] <nevcairiel> not sure it actually has any LFE content in the channel [22:29:36 CEST] <nevcairiel> but it does use L/R/C [22:29:47 CEST] <nevcairiel> ac3 is typically a bit weak in lfe [22:31:11 CEST] <rcombs> durandal_1707: want a sample from a BD that's supposed to be 2.1, but was mis-coded as 3.0? [22:31:19 CEST] <rcombs> (on the disc, afaict) [22:33:47 CEST] <durandal_1707> 2.1 is kind of nice because it have lfe already, could help to compare [22:34:49 CEST] <durandal_1707> nevcairiel: it have lfe always silence, for 3.0 to 3.1 i will just pick center for lfe generation [23:14:46 CEST] <cone-367> ffmpeg 03Kevin Mark 07master:08213e0b7974: libavfilter/scale2ref: Fix out-of-bounds array access [23:14:47 CEST] <cone-367> ffmpeg 03Michael Niedermayer 07master:53e0d5d72475: avformat/options: log filename on open [00:00:00 CEST] --- Sun Jun 4 2017

1 0

ffmpeg.log.20170603
by burek 04 Jun '17

04 Jun '17

[00:00:50 CEST] <furq> pro tip: don't paste the entire nicklist when nobody answers your question [00:01:35 CEST] <furq> also what an unimaginative choice of fakenick. he has so many dinosaurs to choose from [00:01:51 CEST] <tdr> furq, can we expand that to: don't email every email address everywhere to make sure you get your ex? ;) [00:02:24 CEST] <furq> depends what the email says [00:02:31 CEST] <furq> it sounds like it'll probably be quite entertaining [00:15:47 CEST] <johnjay> hey furq I got ffmpeg, yay [00:16:04 CEST] <johnjay> I think I still don't have mpv though. I'm rebuilding now with that mpv_build script thing [00:41:19 CEST] <blue_misfit> hey guys! I'm working with MOV files that have edit lists - I believe ffmpeg has support for these now, but not sure what params I can adjust [00:41:27 CEST] <blue_misfit> is there anything other than -ignore_editlist 1 [00:41:28 CEST] <blue_misfit> ? [01:36:21 CEST] <zerodefect> kepstin: Are you about? [01:36:37 CEST] <kepstin> yo. [01:36:50 CEST] <zerodefect> Discovered the issue with B-Frames. :) [01:37:47 CEST] <zerodefect> I was effectively doing a transcode. What I didn't appreciate is that key_frame and pict_type on the AVFrame from the decoder have a direct affect on the sort of frame generated in the encoder [01:38:37 CEST] <zerodefect> I was decoding a DV-PAL frame so each AVFrame was marked as 'key_frame' and 'pict_type was marked as I-Frame. [01:39:28 CEST] <zerodefect> Live and learn :) [01:40:25 CEST] <kepstin> huh, that hadn't occurred to me. but yeah, I guess that is the api used to request key frames in specific spots in the encoded video :/ [01:42:25 CEST] <zerodefect> Yeah. Are you familiar with dev change process? Would it be fairly easy to commit a change to update the doxygen docs? [01:43:08 CEST] <kepstin> I've done patches for ffmpeg before yeah. For something simple like a doc update it shouldn't be too hard to do. [01:43:35 CEST] <zerodefect> I'll give it a go :) [01:43:37 CEST] <kepstin> (you might want to poke around in #ffmpeg-devel for that sort of thing) [01:43:47 CEST] <zerodefect> Yes, will do. [01:50:03 CEST] <zerodefect> Is it worth asking if this is expected behaviour in #ffmpeg-devel? [02:00:43 CEST] <kepstin> zerodefect: looks like it is - e.g. ffmpeg.c has explicit code to reset the 'pict_type' field to 0 [02:01:32 CEST] <kepstin> (and an ffmpeg.c option exists that causes it to be set to AV_PICTURE_TYPE_I to force a keyframe in certain shots) [02:03:24 CEST] <zerodefect> Ah ok. I'll check that out. [02:08:24 CEST] <zerodefect> Yeah, I see what you mean. It seems to do something with 'quality' too! [02:08:32 CEST] <zerodefect> *something similar [02:22:38 CEST] <kepstin> you should probably just go through the avframe docs and just make sure everything is set sanely; alternatively, you could do something like make a new avframe with cloned/moved buffers but copy over only specific values you want to set [02:30:43 CEST] <zerodefect> That is a good suggestion. [02:30:56 CEST] <zerodefect> I better hit they hay. It's late here. Thanks again for your help. [02:56:32 CEST] <johnjay> kepstin: i got ffmpeg finally! [03:52:02 CEST] <johnjay> furq any idea what I'm doing wrong? I got ffmpeg with that mpv-build thing but mpv itself isn't building [03:52:56 CEST] <johnjay> buffer 4 [12:19:16 CEST] <pokmo> hi [12:19:47 CEST] <pokmo> i'm trying to make segments from my CCTV stream using the command 'avconv -r 7 -i rtsp://192.168.1.100/...stream=0.sdp -acodec aac -strict -2 -vcodec copy -f segment -segment_time 300 -segment_format mp4 "mon1-%03d.mp4"' [12:20:08 CEST] <pokmo> the first segment is fine, but all subsequent segments are black and have no audio [12:20:17 CEST] <pokmo> does anyone know why this might be the case? [12:20:29 CEST] <pokmo> the file sizes look reasonable [12:26:03 CEST] <ChocolateArmpits> pokmo, what are you using to playback the segments ? [12:26:21 CEST] <pokmo> ChocolateArmpits, i'm using quicktime and VLC. the first segment plays back fine. [12:28:09 CEST] <pokmo> here's avconv's output, if that helps: https://dpaste.de/pq1r [12:28:25 CEST] <pokmo> i'm now testing with just segments 5s long [12:30:39 CEST] <pokmo> i wonder if that 'container format requires global headers' warning might be the cause? [12:34:32 CEST] <pokmo> hmm funny. i can view it on dropbox but not VLC [12:34:34 CEST] <pokmo> https://www.dropbox.com/s/1je2ex14l3smrxq/test-001.mp4?dl=0 [12:35:19 CEST] <pokmo> there's a long delay for VLC to play [12:38:15 CEST] <ChocolateArmpits> pokmo, have you tried segmenting to mpegts ? [12:40:22 CEST] <pokmo> ChocolateArmpits, oh! mpegts seems to be better. is it a known issue with mp4? [12:41:14 CEST] <ChocolateArmpits> I didn't have trouble using mp4 with ffmpeg, but I don't the specifics of avconv [12:41:26 CEST] <ChocolateArmpits> Might be some timestamp issue [12:41:45 CEST] <ChocolateArmpits> don't know* [12:42:27 CEST] <pokmo> ChocolateArmpits, mpegts files are somewhat larger than mp4, right? [12:42:38 CEST] <BtbN> pokmo, avconv is not an ffmpeg tool btw. [12:42:41 CEST] <ChocolateArmpits> segmenter is primarily used for hls and that relies on mpegts so I guess the intended compatibility is with that format [12:43:26 CEST] <pokmo> BtbN, oh? is it not? [12:43:30 CEST] <ChocolateArmpits> pokmo, yes it will because each packet has data attached [12:43:30 CEST] <BtbN> no, ffmpeg is. [12:43:53 CEST] <BtbN> And mp4 is not streamable. In theory, you could make a lot of small files every X seconds, but I think the segment muxer is very basic and just cuts the output from the underlying muxer into parts. [12:44:07 CEST] <BtbN> If you really want mp4 segments, you can use the dash muxer [12:46:23 CEST] <pokmo> right [12:46:32 CEST] <pokmo> maybe i should try ffmpeg [12:47:12 CEST] <pokmo> but i guess i'd get the same result, since avconv seems to use ffmpeg [12:48:09 CEST] <pokmo> BtbN, but i'm not trying to stream mp4 though. i'm just trying to make segments in mp4 [12:48:33 CEST] <BtbN> but the format needs to be streamable for the segment muxer I believe [12:49:21 CEST] <kerio> BtbN: fragmented isobmff is streamable tho [12:49:47 CEST] <BtbN> but you still can't enter it at random locations [12:49:52 CEST] <BtbN> that's how DASH works [12:49:57 CEST] <pokmo> well, it's rtsp.. so i guess it's h264 [12:54:55 CEST] <pokmo> is there a way to set the fps of the output segments? [12:55:00 CEST] <kerio> latest HLS also works like that, right [12:55:04 CEST] <pokmo> i've tried "-r 10" but it doesn't seem to work [12:55:25 CEST] <kerio> fragmented mp4 and playlist with fragment byte indices [13:05:55 CEST] <pokmo> BtbN, you were saying how avconv isn't a ffmpeg tool, but if i run avconv --help i get [13:05:57 CEST] <pokmo> ffmpeg version 2.8.11-0ubuntu0.16.04.1 Copyright (c) 2000-2017 the FFmpeg developers [13:06:16 CEST] <BtbN> no idea how that would happen, I blame ubuntu. [13:06:20 CEST] <BtbN> avconv is the libav tool. [13:07:06 CEST] <pokmo> yeah. i installed it from libav-tools [13:07:59 CEST] <pokmo> but then, my ffmpeg doesn't have the -framerate option [13:08:42 CEST] <BtbN> Ubuntu removed libav, and is using ffmpeg again. [13:08:54 CEST] <BtbN> And probably are providing simple symlinks for the old names [13:10:58 CEST] <pokmo> hmm [13:11:26 CEST] <pokmo> BtbN, but is -framerate meant to be a valid option? [13:12:06 CEST] <BtbN> if it says it doesn't know it, probably not [13:12:11 CEST] <pokmo> it's described here though https://en.wikibooks.org/wiki/FFMPEG_An_Intermediate_Guide/image_sequence#F… [13:12:19 CEST] <pokmo> but not under my --help [13:13:01 CEST] <BtbN> no idea if it was removed, is only in libav, or was added in a later version. But yours obviously doesn't have it. [13:13:03 CEST] <BtbN> try -r [13:13:55 CEST] <pokmo> BtbN, yeah, i have. it doesn't seem to affect the fps of my segments [13:16:51 CEST] <pokmo> BtbN, avconv is just a symlink to ffmpeg [15:46:17 CEST] <Guest92861> Hi. I'm trying to extract a frame (losslessly) of an MP4 at a specific time or specific frame (whatever works). I've tried various commands I've found online but I can't get them to work. [15:57:52 CEST] <dystopia_> if you waited more than 5 mins you would have got the answer [16:50:11 CEST] <kepstin> pokmo: framerate is an option specific to certain inputs, e.g. you'll see it if you run "ffmpeg -h demuxer=image2" [16:50:22 CEST] <kepstin> and the same option name is used on e.g. v4l, x11grab, etc. [16:51:05 CEST] <kepstin> but it's an input option, so it can only be used on specific inputs (placed before the -i) [17:14:36 CEST] <kerio> dystopia_: how do you get the image to be lossless tho [17:14:41 CEST] <kerio> does png support yuv420 [17:14:46 CEST] <kerio> or yuv in general [17:16:04 CEST] <kepstin> png? no. But you could probably use jpeg2000 or even just a single-frame lossless h264, i guess. [17:50:20 CEST] <DHE> is there a reason nvenc requirements were raised to nvidia driver version 378 or higher? 375 is still supported... [18:43:35 CEST] <drozdziak1> Any nice free tools for analysing MPEG transport streams you could recommend? Sorry if that's not a good channel for this, but I'm looking at a *.ts's hexdump and it doesn't quite make sense for me. [18:43:51 CEST] <drozdziak1> And I'd like something that would help me understand it better on a higher level first [18:44:28 CEST] <drozdziak1> And I couldn't find any digital tv related IRC channels [18:59:33 CEST] <DHE> wireshark [18:59:38 CEST] <DHE> seriously, open a .ts file in wireshark [19:01:55 CEST] <DHE> drozdziak1: name highlight, see above [19:02:50 CEST] <drozdziak1> DHE: Cool! Thank you! :) [19:03:10 CEST] <DHE> I take it you tried it [19:04:35 CEST] <drozdziak1> Yes, it perfectly names the malformed packets. In fact I'm doing a forensics CTF channels to learn about various data formats. This particular one probably has a channel with missing size data [19:04:53 CEST] <drozdziak1> s/channels challenge [19:41:09 CEST] <SouLShocK> is there an option to make ffmpeg continue reading from the input file, until the input file is closed? i.e. input file is still being written to while ffmpeg reads from it. I already considered -re but that would slow down encoding of all the frames that have already been written to the file [19:43:32 CEST] <c_14> by writing/reading from stdin or a pipe [19:44:16 CEST] <SouLShocK> but not from a file on disk? [19:44:40 CEST] <c_14> nothing that ffmpeg considers seekable really [19:45:05 CEST] <SouLShocK> hm ok [19:45:09 CEST] <DHE> there is a "-follow 1" option but I don't think the ffmpeg CLI will handle it gracefully. I think it's more for API usage [19:46:26 CEST] <BtbN> tail -f ... | ffmpeg -i - ... [19:46:34 CEST] <BtbN> I'd guess that works? [19:46:50 CEST] <DHE> maybe, but can you force it to start from the beginning of the file? [19:47:01 CEST] <BtbN> yeah [19:47:20 CEST] <DHE> looks like -c +0 [19:48:13 CEST] <SouLShocK> interesting idea [19:50:54 CEST] <SouLShocK> yeah tail -f -c +0 | ffmpeg -i - output.mp4 works [19:50:57 CEST] <SouLShocK> thanks [19:54:11 CEST] <BtbN> if you just want to remux, you will want -c copy [19:55:35 CEST] <SouLShocK> nah I'd want to do MXF to MP4 [19:55:43 CEST] <SouLShocK> MPEG2 MXF files that is [21:52:20 CEST] <kosha_> how to set overlay timestamp by mask? [21:52:32 CEST] <kosha_> %h:%m [21:55:05 CEST] <kosha_> like this text='%{localtime\:%T}' but without seconds [21:59:45 CEST] <c_14> replace :T with %H:%M? [21:59:51 CEST] <c_14> *%T [22:01:26 CEST] <kosha_> text='%{localtime\:%H\\:%M}' ? [22:01:47 CEST] <kosha_> ssory [22:01:50 CEST] <kosha_> text='%{localtime\:%H:%M}' ? [22:02:26 CEST] <kosha_> Unterminated %{} near '{localtime:%H' [22:07:56 CEST] <DHE> missing the } at the end, or it's been absorbed by something [22:09:41 CEST] <kosha_> if this text='%{localtime\:%H\:%M}' [22:09:55 CEST] <kosha_> then %{localtime} requires at most 1 arguments [22:10:59 CEST] <c_14> try putting it in quotes [22:12:14 CEST] <kosha_> dont work [22:18:14 CEST] <c_14> "drawtext=text='%{localtime\:%H\\\\\:%M}'" <- works for me [22:18:23 CEST] <kosha_> Oo [22:18:33 CEST] <kosha_> many slashes [22:18:41 CEST] <c_14> If at first you don't succeed, you didn't escape enough [22:19:25 CEST] <DHE> it's the shell's fault, really... :) [22:21:33 CEST] <c_14> well, part of the blame is on shitty filtergraph syntax [22:21:52 CEST] <c_14> if you %{ it should parse until the } in that escaping level [22:23:15 CEST] <kosha_> work [23:05:55 CEST] <arbol> Hi [23:08:33 CEST] <arbol> the ffmpeg contrib tensorflow module keeps telling me that ffmpeg is not installed, although it is. Does anybody know how I could fix this? [23:08:59 CEST] <c_14> probably not finding the include or library directory [23:09:05 CEST] <c_14> is this when building or executing? [23:27:42 CEST] <arbol> I think so too, yes [23:28:47 CEST] <arbol> when executing. concretely, when I run the tensorflow.contrib.ffmpeg.decode_audio operator, it complains that ffmpeg is not installed [23:29:13 CEST] <arbol> (in python) [23:30:00 CEST] <c_14> if it happens during execution it's either looking for the ffmpeg binary and not finding it (check your PATH) or there's a dynamic library that's failing it's linking check your library paths and/or set LD_LIBRARY_PATH [23:35:17 CEST] <arbol> I got it installed with homebrew on mac OS. THe binary is in my path and accessible through os.system so I gueass it should be accessible to tf too. Do you know where is located the ffmpeg library I should add to my LD_LIBRARY_PATH? [23:36:26 CEST] <c_14> eeeeh [23:36:31 CEST] <c_14> /usr/lib /usr/local/lib maybe? [23:36:47 CEST] <c_14> (I don't know where brew puts these things) [23:37:16 CEST] <c_14> check where the binary is `which ffmpeg` , strip the /bin/ffmpeg and check in lib/ [23:38:57 CEST] <arbol> thanks, I think it is indeed /usr/local/lib and it is not in my LD_LIBRARY_PATH [23:39:46 CEST] <c_14> LD_LIBRARY_PATH tends to be empty because that sort of thing is usually handled by setting the paths up in ld.conf [23:43:58 CEST] <arbol> It didn't work but now you;ve said it, I remember seeing some waring fromn brew about including ffmpeg libraries [23:44:26 CEST] <arbol> I'll look into it and maybe come back if I can't solve my problem [23:44:50 CEST] <arbol> Thank you very much [23:47:09 CEST] <arbol> \leave [00:00:00 CEST] --- Sun Jun 4 2017

1 0

ffmpeg-devel.log.20170602
by burek 03 Jun '17

03 Jun '17

[00:00:34 CEST] <atomnuker> yep, there's that gcc flag to use it instead (if you really wanted to) [00:00:55 CEST] <nevcairiel> i've only used that the other way around, to make x86 use sse [00:01:30 CEST] <atomnuker> I don't think intel will ever scrap the old x87, some people will run dos on skylake-x [00:01:35 CEST] <TD-Linux> I wonder when we'll see execution lanes that only support <80 bit precision [00:01:55 CEST] <nevcairiel> well 32-bit x86 mode requires x87 anyway [00:02:10 CEST] <nevcairiel> they could emulate it through sse execution units, no clue if they possibly do that anyway [00:02:45 CEST] <TD-Linux> you can't emulate it (well) with sse because of the reduced precision [00:03:55 CEST] <nevcairiel> i suppose, 80-bits is quite a bit higher then 64 [00:04:14 CEST] <nevcairiel> clearly we need 128-bit floats in avx1024 [00:04:17 CEST] <nevcairiel> :D [00:05:22 CEST] <nevcairiel> (apparently POWER9 gets that) [00:06:00 CEST] <TD-Linux> I'm starting to see posts on fedora-devel about 32-bit packages breaking because upstream only tested with sse2 float, not x87 [00:07:11 CEST] <nevcairiel> i wonder if I can dig up some benchmarks of the difference [00:11:49 CEST] <iive> atomnuker: btw, could you make pvq_search return int, instead of float. sum of Y^2 is integer. [00:15:50 CEST] <jamrial> nevcairiel: x87 was four times slower than sse in compiler generated non-vectorized code of dcadec lfe functions last time i checked [00:16:34 CEST] <jamrial> imo, we should just say fuck pentium 2s and athlon thunderbirds and force -msse -mfpmath=sse as a bare minimum for x86_32 [00:17:08 CEST] <iive> what is the point of forcing sse for C code, just because it is slow on slow cpu's? [00:17:11 CEST] <nevcairiel> some random benchmarks i found seem to suggest that without -msse2 gcc seems not to really use it well [00:18:15 CEST] <nevcairiel> one of these days I should fix the remaining parts so that a -msse2 build on windows doesnt crash all the time [00:18:24 CEST] <nevcairiel> stupid stack alignment [00:18:45 CEST] <nevcairiel> (more precisely, a gcc dll used from msvc app) [00:18:46 CEST] <jamrial> iive: x87 is slow on new cpus as well,a nd x86_32 builds will always use it unless you pass custom CFLAGS to configure [00:19:19 CEST] <iive> jamrial: i think it depends on the default cpu [00:19:29 CEST] <iive> --cpu [00:19:53 CEST] <nevcairiel> i dont think that gets overriden by -march on gcc [00:21:38 CEST] <atomnuker> iive: sure, if that's easier [00:21:57 CEST] <jamrial> --cpu sets -march on GCC, and that doesn't override -mfpmath, which on x86_32 is always x87 by default [00:24:12 CEST] <iive> atomnuker: in the C code, it converts the int to float, before returning it... and on win32 it needs tmp memory to store and load x87 register [00:24:21 CEST] <Shiz> march should set mfpmath [00:24:25 CEST] <iive> i am talking about the ffmpeg --cpu [00:24:31 CEST] <Gramner> -msse2 -mfpmath=sse makes all floating-point C code faster by a decent amount on most cpus on 32-bit x86 if can stand the complaints of people who insist doing multimedia stuff on pentium 2:s is the way to go [00:24:56 CEST] <nevcairiel> my problem is that -msse2 makes my DLLs crash due to windows stack alignment crappyness [00:25:07 CEST] <nevcairiel> and ffmpeg doesnt compile with -mstackrealign [00:25:18 CEST] <atomnuker> iive: just return an int, it'll get converted automatically when sqrtfing it [00:25:39 CEST] <atomnuker> (I gotta check that asm you sent me) [00:25:46 CEST] <iive> atomnuker: i'm not sure the assembler works like this. [00:26:15 CEST] <iive> atomnuker: it returns float, i tested it on linux 32 too, so it probably works :D [00:27:27 CEST] <iive> nevcairiel: there are attributes that could realign specific functions, does ffmpeg use that for api entry functions? [00:27:39 CEST] <nevcairiel> only for the main api [00:27:44 CEST] <nevcairiel> like decode and filtering [00:27:53 CEST] <nevcairiel> but the crashes happen in all sorts of random functions that use floats [00:28:04 CEST] <nevcairiel> like options setting [00:28:38 CEST] <nevcairiel> let me build such a binary and see [00:28:40 CEST] <iive> hum... that's strange, sse does have a bunch of scalar operations and could be used without needing stack alignment [00:28:56 CEST] <nevcairiel> it only happens with -msse2 [00:29:11 CEST] <nevcairiel> maybe gcc got smarter and -mstackrealign works now with ffmpeg [00:29:16 CEST] <nevcairiel> lets see [00:31:15 CEST] <iive> atomnuker: on the other side, i could just return sqrt(syy)... [00:31:52 CEST] <iive> then it would be float [00:35:09 CEST] <kiroma> May I have a small question? [00:36:13 CEST] <iive> go ahead kiroma [00:36:26 CEST] <kiroma> Have you considered changing from autoconf to cmake? [00:36:40 CEST] <nevcairiel> we dont use autoconf [00:37:06 CEST] <kiroma> Oh. [00:38:12 CEST] <nevcairiel> configure is a big custom shell script [00:38:21 CEST] <nevcairiel> its not autotools, even if it shares the configure name [00:38:32 CEST] <iive> and options style [00:39:02 CEST] <kiroma> yeah since it shares name I just assumed it used autoconf. [00:40:56 CEST] <iive> always check your assumptions [00:41:55 CEST] <kiroma> Is there a reason you created a whole custom script for generating a makefile instead of using tools like cmake/autoconf? [00:42:35 CEST] <nevcairiel> we dont generate the makefiles, we just configure them [00:43:06 CEST] <nevcairiel> also, autotools is horrible and cmake probably didnt even exist back then [00:43:45 CEST] <nevcairiel> cmake also doesnt deal very well with massive configurable build like ffmpegs, in my experience anyway [00:43:57 CEST] <nevcairiel> its configuration syntax is terrible [00:45:50 CEST] <J_Darnley> BBB: It looks like the 10-bit is doing the vertical transform first. Am I reading this right? [00:46:51 CEST] <kiroma> Does it? I had no problem compiling stuff like blender. [00:47:18 CEST] <kiroma> And yeah, it seems that cmake had its initial release right before ffmpeg was created. [00:48:42 CEST] <J_Darnley> Is there any build tool that isn't utter shit? I honestly think ffmpeg's hand written one is one of the least worst around. [00:49:01 CEST] <nevcairiel> most of them are a bit crappy in some area [00:52:38 CEST] <kiroma> Well ffmpeg's one has been created for ffmpeg, while I imagine most build tools need to be as universal as possible. [00:56:06 CEST] <kiroma> Also, the thing I like about cmake is the configurability. [00:57:16 CEST] <kiroma> As an end-user, I have no problem changing any part of the build environment, finding missing dependencies, etc... [01:01:00 CEST] <J_Darnley> Argh. I don't get it. This is totally doing vertical transform first. Furthermore it looks like 8-bit should work if I give the right options to these macros. [01:02:27 CEST] <nevcairiel> i wonder if gcc is disobeying me, i can clearly see it using x87 instructions, even though I told it not to [01:04:09 CEST] <nevcairiel> these functions take floats as parameters, so i guess it has no choice because of the calling convention, but should it then decide to keep using x87? [01:04:37 CEST] <wm4> lol as if cmake isn't garbage [01:04:40 CEST] <wm4> and autotools [01:04:56 CEST] <wm4> though suffering through configure's cryptic shit isn't nice either [01:06:31 CEST] <wm4> basically everything sucks and is terrible [01:06:34 CEST] <rcombs> ^ [01:08:17 CEST] <wm4> maybe I should try meson again [01:09:09 CEST] <J_Darnley> I've been meaning to try that on my own project since FOSDEM [01:16:07 CEST] <nevcairiel> hm, apparently gcc has gotten smarter [01:16:11 CEST] <nevcairiel> it fixes these problems on its own now [01:17:21 CEST] <J_Darnley> Wow, gcc improves quickly. [01:18:14 CEST] <jamrial> if only people upgraded as quickly [01:18:25 CEST] <jamrial> we keep getting bug reports of builds done with 4.x gcc :p [01:18:47 CEST] <nevcairiel> it can build ffmpeg with -mstackrealign now, and it even automatically enables that option if you enable sse/sse2 on windows [01:19:26 CEST] <nevcairiel> with -msse2 and -mno-stackrealign it still crashes as before, to confirm [01:19:54 CEST] <nevcairiel> hm weird [01:20:02 CEST] <nevcairiel> instead of aligning the stack it just seems to stop using sse2 [01:20:07 CEST] <nevcairiel> wonder if thats intended =p [01:20:16 CEST] <atomnuker> iive: I meant in the C code, not the asm [01:21:07 CEST] <iive> atomnuker: well, i'm not quite sure how the linker would know know what the asm function returns... [01:21:37 CEST] <J_Darnley> I had to look deep into the manual to find a stack align attribute. Luckily the project mentioned above only has one entry point from Windows. [01:21:48 CEST] <atomnuker> iive: by changing it to return an int.. [01:22:16 CEST] <iive> you mean, the definition :) [01:22:33 CEST] <iive> or is it declaration... i always swap these. [01:22:39 CEST] <nevcairiel> still seems very odd that it would just stop using sse2, does it like deduce that the prologue is more expensive then not using sse2? [01:23:05 CEST] <nevcairiel> (this is on gcc 6.3) [01:31:42 CEST] <BBB> J_Darnley: I believe so, yes [01:31:53 CEST] <BBB> J_Darnley: and then the coefficients are written in the array pre-transposed already [01:40:53 CEST] <rcombs> nevcairiel: I've been using -mstackrealign for windows for a while, yeah [01:41:20 CEST] <nevcairiel> rcombs: then tell me why it just disables sse/sse2 instruction use :D [01:41:26 CEST] <rcombs> didn't realize -msse2 triggered that by default, though [01:41:28 CEST] <nevcairiel> instead of aligning the stack [01:41:36 CEST] <rcombs> wait wat [01:41:46 CEST] <rcombs> in my experience it aligns the stack like it's supposed to [01:41:55 CEST] <nevcairiel> thats what i'm seeing here right now [01:41:55 CEST] <rcombs> else we'd be seeing crashes in ASM functions [01:42:16 CEST] <nevcairiel> everything using yasm code has the explicit align flag in the code [01:42:27 CEST] <nevcairiel> so the compiler is forced to do it [01:42:30 CEST] <rcombs> oh huh [01:42:41 CEST] <rcombs> isn't aligning the stack like, one instruction [01:42:52 CEST] <nevcairiel> it eats a register [01:42:55 CEST] <rcombs> and esp, 0xsomething? [01:43:22 CEST] <rcombs> I guess it forces you to have a frame pointer where you might not otherwise [01:43:54 CEST] <nevcairiel> i'm looking at av_reduce because thats something I just had crash, with -mno-stackrealign it uses xmm regs [01:43:59 CEST] <nevcairiel> with -mstackrealign it doesnt [01:44:06 CEST] <nevcairiel> but the prologue doesnt otherwise change at all [01:44:21 CEST] <rcombs> and with -msse2 it has the -mstackrealign behavior? [01:44:32 CEST] <rcombs> (if you don't explicitly specify one way or the other) [01:44:35 CEST] <nevcairiel> it has that no matter what -m i pick [01:44:40 CEST] <nevcairiel> but yea [01:44:55 CEST] <nevcairiel> obviously with -mno-stackrealign it just crashes [01:45:04 CEST] <nevcairiel> but it does use sse2 [01:45:30 CEST] <nevcairiel> gcc is weird [01:45:47 CEST] <nevcairiel> i wonder if i can somehow find out if it actually uses sse2 anywhere outside of asm functions [01:47:39 CEST] <rcombs> nm, grep for movdq? [01:48:02 CEST] <nevcairiel> next test, actually disable attribute_align_arg from doing anything and see if gcc realigns anywhere at all [01:48:09 CEST] <nevcairiel> i should grab gcc 7 and see if something changed [01:49:59 CEST] <nevcairiel> hm yeah that crashes [01:50:04 CEST] <nevcairiel> i think -mstackrealign doesnt do shit [01:50:20 CEST] <nevcairiel> well, other then disabling sse(2) [01:50:24 CEST] <rcombs> I think I'm on a somewhat old gcc [01:51:39 CEST] <rcombs> https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02133.html [01:52:50 CEST] <nevcairiel> so they only align the stack when needed, and cant really figure it out properly? [01:52:53 CEST] <nevcairiel> sounds...useful [01:55:17 CEST] <nevcairiel> you can force it to do it everywhere by using -mincoming-stack-boundary, but that explodes in various inline asm things [01:55:52 CEST] <nevcairiel> at least enabling -msse2 should be s omewhat save then [01:56:32 CEST] <rcombs> welp [01:56:48 CEST] <rcombs> we're improving our build tools so hopefully I can start making an x86_64 windows build soon [01:57:06 CEST] <rcombs> and then if the x86 build is performing poorly because of this shit I can just tell people to use that instead [01:57:30 CEST] <rcombs> (I mean, I already know switching to x86_64 should yield a significant improvement in x264 perf) [01:57:32 CEST] <nevcairiel> well its only for generic C code anyway [01:57:45 CEST] <nevcairiel> so the difference is probably minimal either way [01:57:48 CEST] <rcombs> yeah, so probably not a huge deal [01:57:50 CEST] <rcombs> but still [01:58:50 CEST] <nevcairiel> was just surprising me [01:59:27 CEST] <rcombs> same [01:59:53 CEST] <nevcairiel> it seems to generally work though otherwise [02:00:20 CEST] <nevcairiel> i checked stuff like the dca dsp that jamrial suggested to gain a speed improvement from using fpmath=sse, and it has the align header [02:01:09 CEST] <nevcairiel> (even though technically not necessary, since its shielded behind the explicit align from decode_audio) [02:12:43 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:75697b500c3e: avcodec/tiff: reset sampling[] if its invalid [02:12:44 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:b147ded288ea: avcodec/svq3: Fix runtime error: left shift of negative value -6 [02:12:45 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:72e5ccfe3783: avcodec/truemotion1: Fix multiple runtime error: signed integer overflow: 1246906962 * 2 cannot be represented in type 'int' [02:12:46 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:21d50c185db0: avcodec/scpr: mask bits to prevent out of array read [02:12:47 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:b7b28b6aadd4: avcodec/hq_hqa: Fix: runtime error: signed integer overflow: -255 * 10180917 cannot be represented in type 'int' [02:12:48 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:f34dc82d566c: avcodec/takdec: Fix runtime error: left shift of negative value -42 [02:12:49 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:6e788fadaee9: avcodec/mlpdec: Fix runtime error: left shift of negative value -1 [02:12:50 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:6ebb9e7b7765: avcodec/flicvideo: Check frame_size before decrementing [02:12:51 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:fedd8b65077d: avcodec/fmvc: Fix off by 1 error [02:12:52 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:41867021840d: avcodec/aacdec_template: Fix fixed point scale in decode_cce() [02:12:53 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:72e5607c8758: avcodec/aacdec: Fix runtime error: signed integer overflow: 2147483520 + 255 cannot be represented in type 'int' [02:12:54 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:b6c0ad571f60: avcodec/dfa: Fix: runtime error: signed integer overflow: -14202 * 196877 cannot be represented in type 'int' [02:12:55 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:686eb3b1ed5b: avcodec/mlpdec: Fix: runtime error: left shift of negative value -8 [02:12:56 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:fc7c37906077: avcodec/pixlet: Fix reading invalid numbers of bits [02:12:57 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:f254c7ea1397: avcodec/fic: Fix multiple runtime error: signed integer overflow: 5793 * 419752 cannot be represented in type 'int' [02:12:58 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:e46bc3052dc1: avcodec/mimic: Use ff_set_dimensions() to set the dimensions [02:12:59 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:f3b6ea14081a: avcodec/aacsbr_fixed: Fix multiple runtime error: shift exponent 150 is too large for 32-bit type 'int' [02:13:00 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:e605faaabcf8: avcodec/mlpdec: Do not leave a invalid num_primitive_matrices in the context [02:13:01 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:9c65a87bd48e: avcodec/aacsbr_fixed: Fix multiple runtime error: shift exponent 170 is too large for 32-bit type 'int' [02:13:02 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:f397613f0595: avcodec/sbrdsp_fixed: fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int' [02:13:03 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:a5875f8a1e55: avcodec/mlpdsp: Fix runtime error: signed integer overflow: -24419392 * 128 cannot be represented in type 'int' [02:13:04 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:ff4f52590529: avcodec/takdec: Fix runtime error: left shift of negative value -63 [02:13:05 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:f832d7361d03: avcodec/aac_defines: Fix: runtime error: left shift of negative value -2 [02:13:06 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:3cfb01607144: avcodec/takdec: Fix runtime error: signed integer overflow: 8192 * 524308 cannot be represented in type 'int' [02:13:07 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:0ea475942e75: avcodec/vmnc: Check location before use [02:13:08 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:d11c686204b4: avcodec/vp9block: fix runtime error: signed integer overflow: 196675 * 20670 cannot be represented in type 'int' [02:13:09 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:a7442f8d357d: avcodec/mpeg4videodec: Check for multiple VOL headers [02:13:10 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:e73efe469112: avcodec/aacdec_fixed: Fix runtime error: shift exponent 34 is too large for 32-bit type 'int' [02:13:11 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:17a4e791bfe5: avcodec/mjpegdec: Fix runtime error: signed integer overflow: -32767 * 130560 cannot be represented in type 'int' [02:13:12 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:abd5277318c5: avcodec/ivi_dsp: Fix multiple runtime error: left shift of negative value -71 [02:13:13 CEST] <cone-477> ffmpeg 03Max Justicz 07release/3.3:6b839e9aa336: avcodec/fmvc: Fix use of uninitialized memory when the first frame is not a keyframe [02:13:14 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:ba7ea7c4b1aa: avcodec/jpeglsdec: Check get_bits_left() before decoding a picture [02:13:15 CEST] <cone-477> ffmpeg 03Max Justicz 07release/3.3:861c05b286f2: avcodec/sanm: Fix uninitialized reference frames [02:13:16 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:38fd2a33b93c: avcodec/jpeg2000dec: Check tile offsets [02:13:17 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:80cebb992c2d: avcodec/jpeg2000dec: Fix copy and paste error [02:13:18 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:190787a02630: avcodec/diracdec: Fix off by 1 error in quant check [02:13:19 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:a49743407bc6: avcodec/smc: Check remaining input [02:13:20 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:f85a71527a8b: avcodec/aacdec_fixed: Fix runtime error: signed integer overflow: -2147483648 * -1 cannot be represented in type 'int' [02:13:21 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:4e8c5721b356: avcodec/clearvideo: Check buf_size before decoding frame [02:13:22 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:42163d4c551d: avutil/internal: Do not enable CHECKED with DEBUG [02:13:23 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:92a23e2a639c: avformat/mux: Fix copy an paste typo [02:13:24 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:dbff2d602d86: avcodec/pixlet: Fix runtime error: signed integer overflow: 2147483647 + 32 cannot be represented in type 'int' [02:13:25 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:b803624aae4c: avcodec/ra144dec: Fix runtime error: left shift of negative value -17 [02:13:26 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:75d881f1a979: avcodec/mlpdec: Do not leave invalid values in matrix_out_ch[] on error [02:13:27 CEST] <cone-477> ffmpeg 03Kevin Mark 07release/3.3:573e40e8f1c3: doc/filters: Clarify scale2ref example [02:13:28 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:f5626db24e78: avcodec/ivi_dsp: Fix runtime error: left shift of negative value -2 [02:13:29 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:c0895d64f5fa: avcodec/sbrdsp_template: Fix: runtime error: signed integer overflow: 849815297 + 1315389781 cannot be represented in type 'int' [02:13:30 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:d2476bd465a1: avcodec/libfdk-aacdec: Correct buffer_size parameter [02:13:31 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:1d589a93b07c: avcodec/wnv1: More strict buffer size check [02:13:32 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:b330fec1ced7: avcodec/aacdec_fixed: Fix multiple runtime error: shift exponent 127 is too large for 32-bit type 'int' [02:13:33 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:3e18f0fddde8: avcodec/sheervideo: Check input buffer size before allocating and decoding [02:13:34 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:cd3314552b24: avcodec/jpeg2000dec: Check tile offsets more completely [02:13:35 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:bc2cbb307761: avcodec/jpeg2000: Fix runtime error: signed integer overflow: 4185 + 2147483394 cannot be represented in type 'int' [02:13:36 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:586e00d7d3ec: avcodec/snow: Fix runtime error: signed integer overflow: 1086573993 + 1086573994 cannot be represented in type 'int' [02:13:37 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:b419c7564c5f: avcodec/ylc: Check count in build_vlc() [02:13:38 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:be9268e35044: avcodec/aacdec_fixed: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int' [02:13:39 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:080edf29e74a: avcodec/webp: Fixes null pointer dereference [02:13:40 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:b578ba915f07: avcodec/aac_defines: Add missing () to AAC_HALF_SUM() macro [02:13:41 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:22dab0f4e1b8: avcodec/ra144: Fix runtime error: signed integer overflow: 11184810 * 404 cannot be represented in type 'int' [02:13:42 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:3a0e4368ec5a: avcodec/ra144: Fix runtime error: signed integer overflow: -2449 * 1398101 cannot be represented in type 'int' [02:13:43 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:722cc62baa98: avcodec/truemotion2: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int' [02:13:44 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:ece91a3918ca: avcodec/truemotion2: Fix passing null pointer to memset() [02:13:45 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:0a0eec60c878: avcodec/jpeg2000dec: Use ff_set_dimensions() [02:13:46 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:d59e6cef7902: avcodec/dds: Fix runtime error: left shift of 145 by 24 places cannot be represented in type 'int' [02:13:47 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:c1074aea7131: avcodec/ansi: Fix frame memleak [02:13:48 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:a24cd04074c8: avcodec/wavpack: Fix runtime error: signed integer overflow: 24 * -2147483648 cannot be represented in type 'int' [02:13:49 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:795f65eed59d: avcodec/wavpack: Check float_shift [02:13:50 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:003cce421da6: avcodec/acelp_pitch_delay: Fix runtime error: value 4.83233e+39 is outside the range of representable values of type 'float' [02:13:51 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07release/3.3:1998147f2ebc: avformat/avidec: Limit formats in gab2 to srt and ass/ssa [02:13:52 CEST] <cone-477> ffmpeg 03Micah Galizia 07release/3.3:771206c0dbb4: libavformat/http: Ignore expired cookies [02:13:53 CEST] <cone-477> ffmpeg 03Micah Galizia 07release/3.3:e5e01d24773d: libavformat/hls: Observe Set-Cookie headers [02:42:02 CEST] <kierank> av500: https://stackoverflow.com/users/1559108/av501 [02:42:06 CEST] <kierank> you have some kind of secret admirer [04:20:16 CEST] <KGB> [13FFV1] 15dericed opened pull request #67: upgrading to a working group document (06master...06wg-document) 02https://git.io/vHuEK [06:23:58 CEST] <av500> kierank: ! [09:18:01 CEST] <thebombzen> the copyright date in ffmpeg.c is listed as 2000-2003. is this intentional [09:18:15 CEST] <thebombzen> specifically it's copyright Fabrice Bellard 2000-2003 [09:18:34 CEST] <thebombzen> should the copyright info be updated? [09:44:16 CEST] <alevinsn> thebombzen: That may be correct for Fabrice's involvement [09:44:28 CEST] <alevinsn> and other people that have worked on this file haven't bothered to alter the copyright statement [09:51:47 CEST] <ubitux> is AAC PS a subsystem or it belongs in decoders? (tests/checkasm/Makefile) [09:51:54 CEST] <ubitux> it looks only used by the AAC decoders [09:51:56 CEST] <ubitux> -s [09:52:25 CEST] <ubitux> OTOH the dsp init doesn't even explicit aac ("PSDSPContext") [09:52:41 CEST] <ubitux> it doesn't look used outside of AAC currently, but maybe it could? [09:53:05 CEST] <ubitux> i see that h264 stuff is actually considered a "subsystem" thing [09:53:18 CEST] <ubitux> just like flac and vp8 [09:53:32 CEST] <ubitux> are they that much shared that they belong in the "subsystem" category? [10:00:37 CEST] <ubitux> (lol @ "MMX implied by specified flags" when running aarch64 tests) [10:05:07 CEST] Action: mateo` starts to add emms_c calls all around the aarch64 codebase [11:05:10 CEST] <wm4> nevcairiel: "Unable to decrypt message (error 0x80090330) " -> seems like this is SEC_E_DECRYPT_FAILURE [11:10:00 CEST] <nevcairiel> does that happen with a particular server or something? [11:12:00 CEST] <wm4> it happens with our media server, but only for 1 user [11:13:57 CEST] <nevcairiel> is he like on XP or something crazy [11:14:39 CEST] <wm4> "Windows 7 SP 1" [11:14:44 CEST] <wm4> so, almost [11:20:20 CEST] <nevcairiel> without being able to reproduce it, i have no idea [11:24:55 CEST] <nevcairiel> does it like not work at all for that guy? or is that a random failure? [11:25:12 CEST] <wm4> doesn't seem to work at all [11:25:34 CEST] <wm4> the error always happens when it tries to read data from the newly opened https connection, I think [11:28:28 CEST] <nevcairiel> can anything else access the server over https then? maybe the cert got screwed up? [11:31:00 CEST] <nevcairiel> i'm not claiming tls_schannel is possibly the most error free code ever, but a single user with a odd problem .. experience shows, it may not be your code =p [11:31:27 CEST] <wm4> yeah, that's what I'm thinking too [11:31:42 CEST] <wm4> it worked fine for too many users in too many places [11:45:51 CEST] <stevenliu> What about add time into line head of every line log? [11:46:40 CEST] <stevenliu> for example: [2017-06-02 17:46:32] frame= 137 fps=4.5 q=-1.0 Lsize= 2323kB time=00:00:05.44 bitrate=3497.0kbits/s speed=0.179x [11:48:30 CEST] <stevenliu> user can recover the problem message from which time (YYYYMMDD hhmmss) [11:49:03 CEST] <nevcairiel> real time is not necessarly useful for that [11:51:54 CEST] <stevenliu> some stream is always online, some people pull the stream by ffmpeg, and there have problem sometimes, they maybe need find the problem happend time, be used to seek the error log on server. [11:52:11 CEST] <stevenliu> they usually run ffmpeg background [11:52:34 CEST] <stevenliu> or, add an option to control it? [11:53:00 CEST] <stevenliu> control if they need the real time header? [11:53:17 CEST] <ubitux> doesn't -report print the time? [11:54:00 CEST] <ubitux> i'd rather have it in the report, which is what you're supposed to log i think [11:54:40 CEST] <stevenliu> no, not that mean [11:55:08 CEST] <stevenliu> ffmpeg-20170603-015319.log this is time of log file create time? [11:55:45 CEST] <stevenliu> i mean the context of the log, every line or warning line, or error line [11:57:41 CEST] <stevenliu> for example: the line of log "cur_dts is invalid (this is harmless if it occurs once at the start per stream)", if show this log, people maybe need know "what the time dose this problem happend? [11:59:04 CEST] <stevenliu> add the real time into -report? ubitux [11:59:37 CEST] <ubitux> i guess [12:00:02 CEST] <stevenliu> ah, that's a better way :D let me try it [12:38:17 CEST] <ubitux> so ld* on lower part of the reg trashes the higher? (aarch64) [12:39:02 CEST] <ubitux> :( [12:39:04 CEST] <ubitux> i'm sad :( [12:43:53 CEST] <stevenliu> Inner peace :) [12:44:50 CEST] <stevenliu> What about add the time string into av_log_format_line2 ? [12:45:17 CEST] <stevenliu> or add it into log_callback_report at cmdutils.c ? [12:45:25 CEST] <nevcairiel> if anywhere it should be in ffmpeg.c or wherever, the log things in avutil are not configurable [12:46:15 CEST] <wbs> ubitux: yes, most operations on a wX register explicitly clears the upper half of the register [12:46:47 CEST] <wbs> (which means that it's easy to miss to sign extend registers because the cases where the upper half contains garbage is prety rare) [12:47:02 CEST] <wbs> but checkasm tests that at least, for anything that is hooked up there [12:47:26 CEST] <wm4> stevenliu: yeah, I'd also prefer tom put it outside of the libs [12:47:31 CEST] <wm4> *to [12:47:53 CEST] <ubitux> wbs: yeah that's how i figured it out (with checkasm) [12:48:01 CEST] <ubitux> i was reading in lower part of v8 [12:48:41 CEST] <wbs> ah right, for vector registers as well - yes [12:48:48 CEST] <wbs> you can't treat them as two halves any longer [12:49:03 CEST] <ubitux> :( [12:49:23 CEST] <stevenliu> wm4, ok, let me try add it into cmdutils :) [12:49:42 CEST] <ubitux> in checkasm, what is the purpose of the name argument for check_func()? [12:49:48 CEST] <ubitux> it doesn't seem to be displayed [12:50:18 CEST] <wbs> for benchmarking [12:50:52 CEST] <wbs> if you run with --bench or --bench=<prefix> it will list the names, and only benchmark and list the functions starting with prefix, respectively [12:51:09 CEST] <ubitux> mmh, ok [12:51:23 CEST] <ubitux> i can't test --bench right now with qemu it seems [12:51:30 CEST] <ubitux> i'll try it out on a board [12:51:31 CEST] <ubitux> thanks [12:51:43 CEST] <wbs> there's no point in using --bench unless on a real cpu [12:51:58 CEST] <wbs> and even then, you need to enable user mode access to cycle counters, which you need to do from kernel space [12:52:02 CEST] <ubitux> except to test how the name is printed :p [12:52:13 CEST] <ubitux> it was more about testing the bench option more than anything else [12:53:08 CEST] <wbs> ah, k [12:53:20 CEST] <wbs> well it will probably still give you a quick SIGILL :P [12:53:38 CEST] <wbs> testing the string output is probably easier done on an x86 system [13:07:19 CEST] <ashk43712> Hi, how to get the path of a main/ref video in ffmpeg through filters? [13:49:11 CEST] <J_Darnley> ashk43712: I doubt you can. [14:04:55 CEST] <wm4> I doubt you should... [14:23:39 CEST] <nevcairiel> man this guys reponses are literally unreadable [14:23:43 CEST] <nevcairiel> how can some mail clients be so crappy [14:25:00 CEST] <BtbN> Looks like some really bad web mailer or something [14:25:27 CEST] <BtbN> but yeah, I am unable to find the response in his responses [14:25:36 CEST] <BtbN> I'll probably just do that patch myself, properly. [14:25:43 CEST] <BtbN> Use static if available, otherwise shared, otherwise error. [14:26:09 CEST] <BtbN> But some way to select on specifically would be nice [14:26:58 CEST] <BtbN> That beeing said... what about just deprecating the scale_npp thing? We have scale_cuda now. [14:27:01 CEST] <nevcairiel> we dont really allow that for anything, its basically up to you to expose the library you want to link against [14:27:12 CEST] <nevcairiel> be it shared or static [14:27:23 CEST] <BtbN> well, libnpp has diffrent names for shared and static [14:27:28 CEST] <BtbN> and both are available usually [14:27:47 CEST] <nevcairiel> and yeah, if scale_cuda works equally well, should just get rid of npp [14:28:15 CEST] <BtbN> libnpp has the algorithm selection thing, but it's broken anyway and most of them just end up with the exact same result [14:36:14 CEST] <BBB> hmm& https://www.wired.com/2017/06/diversity-open-source-even-worse-tech-overall/ [14:38:11 CEST] <nevcairiel> i think its silly to say "open source has work to do", its not like we block anyone, but should it be our job to lobby to get more women? we should lobby to get competent devs of all types and colors [14:38:56 CEST] <BtbN> Specially with potentially anonymous open source contributions, nobody really cares [14:39:12 CEST] <BtbN> Usually projects take any good contribution they can get [14:39:34 CEST] <Compn> wait [14:39:48 CEST] <Compn> the article should be complaining about women in the software field at all [14:40:04 CEST] <Compn> this isnt an open source problem, but closed source as well [14:40:06 CEST] <BBB> were so perfect :) [14:40:15 CEST] <BBB> the numbers speak differently, compn [14:40:20 CEST] <BBB> read the numbers [14:40:29 CEST] <BBB> or if you disagree with them, thats ok also, but explain why [14:40:42 CEST] <BBB> but the numbers suggets opensource is worse than software overall [14:41:30 CEST] <Compn> i see no numbers from closed source companies, BBB [14:41:38 CEST] <BBB> overall [14:42:08 CEST] <BBB> Of that randomly selected cohort, a full 95 percent of respondents were male. Only three percent identified as female and one percent as non-binary. According to Bureau of Labor Statistics, about 22.6 percent of professional computer programmers are female. [14:42:17 CEST] <BBB> 3 and 22.6 are very different [14:42:33 CEST] <Compn> yes thats the open source and labor numbers [14:42:36 CEST] <BtbN> "negative interactions such as rudeness", I have never seen a project that's not equally rude to everyone. [14:42:43 CEST] <Compn> i'm asking about closed source, specifically [14:43:10 CEST] <BBB> why would closed source be fundamentally different from professional computer programmers overall? [14:43:12 CEST] <nevcairiel> BtbN: presumably being rude to other males is ok while being rude to females is well .. rude. you know how this goes =p [14:43:44 CEST] <BBB> anyway, lets not start a fight just yet, we need some matches left for VDD this year ;) [14:43:47 CEST] <Compn> BBB : hue hue hue [14:43:58 CEST] <BBB> :D [14:44:19 CEST] <Compn> BBB : you've worked at various closed source companies [14:44:26 CEST] <BBB> I have [14:44:31 CEST] <Compn> whats the male-female programmer ratio you've personally seen ? [14:44:35 CEST] <nevcairiel> I also always thought things like Outreachy are the wrong way to go. Isn't it discrimenating against the average male if they can't join such a program just because they are "normal"? :P [14:44:52 CEST] <BBB> very team-dependent [14:44:56 CEST] <Compn> nevcairiel : meh, another double standard i dont mind :P [14:45:00 CEST] <BBB> in my team @ google, I dont think it was 20%, but probably well over 10% [14:45:14 CEST] <Compn> BBB : overall numbers, count totals [14:45:24 CEST] <Compn> not per team [14:45:28 CEST] <BBB> Im pretty sure 20% would not be a bad guess for google [14:45:40 CEST] <Compn> not bad [14:45:41 CEST] <Compn> hehe [14:45:48 CEST] <BBB> but variance is important also, if certain teams are women-only and others are men only, that suggests you didnt really solve the issue [14:46:02 CEST] <nevcairiel> truth be told, i 've never actually directly worked with a female developer, I saw some in other teams, but its rare [14:46:09 CEST] <nevcairiel> I know a female sysadmin =p [14:46:28 CEST] <Compn> i've known a female sysadmin , AND i was rude to her! [14:46:28 CEST] <thardin> this will change, but fairly slowly [14:46:43 CEST] <nevcairiel> she is routinely rude to everyone, so its ok! [14:46:46 CEST] <thardin> the gender distribution in CS does seem to be improving [14:46:52 CEST] <thardin> partly due to outreach programs [14:46:58 CEST] <Compn> she only had one eye, so i was also rude to a disabled! [14:47:10 CEST] <Compn> i dont discriminate in my rudeness :D [14:47:23 CEST] <BBB> thats not nice at all [14:47:29 CEST] <nevcairiel> yeah this entire thing has to start in education first, can't expect the numbers in the industry to drastically change before universitys do [14:47:46 CEST] <Compn> enter the exciting world of .... programming [14:48:01 CEST] <thardin> yes. but I suspect it has to start much earlier. this all start extremely early. like pre-school early [14:48:11 CEST] <thardin> sexist bullshit etc [14:48:18 CEST] <nevcairiel> I think it is exciting, instead i find watching sports rather boring, everyone their own =p [14:49:11 CEST] <Compn> irc numbers are low as well, for the womens [14:49:31 CEST] <thardin> depends on the channel [14:49:31 CEST] <nevcairiel> irc is a dying medium, all the cool kids dont use it anymore [14:49:38 CEST] <Compn> i take a look at my life and see that a lot of my hobbies and such have low ratios of females hah [14:49:51 CEST] <J_Darnley> You mean women aren't dumb enough to do labour for free? [14:50:03 CEST] <BBB> you get paid J_Darnley [14:50:04 CEST] <nevcairiel> way to put the fail onto us J_Darnley [14:50:07 CEST] <thardin> they already do J_Darnley [14:50:23 CEST] <Compn> did you just assume my gender?! :P [14:50:41 CEST] <Compn> hmm maybe is too rude [14:50:47 CEST] <thardin> edgy [14:50:50 CEST] <nevcairiel> everyone knows Compn is a genderless Amoeba [14:51:21 CEST] <J_Darnley> BBB: sure, now [14:51:26 CEST] <BBB> \o/ [14:51:31 CEST] <BBB> how is the idct? [14:51:39 CEST] <BBB> making progress? or need help [14:51:40 CEST] <BBB> ? [14:51:57 CEST] <J_Darnley> Not right now. [14:52:41 CEST] <J_Darnley> I tried passing the "right" options to the 10-bit macros but that didn't work so now I am looking more closely. [14:53:11 CEST] <stevenliu> Women programmer numbers less then men ... [14:53:55 CEST] <BBB> when you initalize the function pointer, did you set the idct_perm correctly? [14:54:07 CEST] <stevenliu> there have lots women programmer in China, and use ffmpeg :D [14:54:19 CEST] <J_Darnley> Ah, I probably didn't [14:54:26 CEST] Action: J_Darnley goes to try that again [14:55:09 CEST] <BBB> J_Darnley: so, you need to set the idct_perm for the sse2 version based on the 10bit macros to the same values as the ones for the 10bit functions, not the one for the mmx2 function you ported earlier [14:55:39 CEST] <BBB> I Can try to explain but it may be more confusing [14:56:11 CEST] <J_Darnley> I understand that. I've seen the different flag. [14:58:09 CEST] <J_Darnley> Oh wow. That does work. [14:58:12 CEST] <BBB> \o/ [14:58:16 CEST] <BBB> very cool [14:58:18 CEST] <BBB> is it faster? [14:59:05 CEST] <J_Darnley> Yes, a little [14:59:19 CEST] <J_Darnley> But I take back the "working" statement. [14:59:42 CEST] <J_Darnley> The dct test passes but it isn't the same as the C and MMX [15:00:34 CEST] <J_Darnley> (It is about 40% faster) [15:00:51 CEST] <J_Darnley> Now I better check the rest of fate. [15:03:04 CEST] <BBB> the rounding may be a little bit different [15:03:14 CEST] <BBB> I dont think its hard to fix that [15:03:33 CEST] <BBB> it can probably be done using the correct macro arguments, but I dont recall exactly how to do that or what they should be [15:03:49 CEST] <BBB> if you send a patch I can try to fix the rounding [15:03:56 CEST] <BBB> 40% is pretty great [15:04:13 CEST] <BBB> esp. because it doesnt optimize for zero in any way (or even dc-only) [15:04:17 CEST] <J_Darnley> Maybe. Also two of the coeffs differ by +1 and -1 [15:05:31 CEST] <BBB> coefs? [15:05:35 CEST] <BBB> you mean residual post-idct? [15:05:45 CEST] <BBB> or input coefs? [15:05:57 CEST] <J_Darnley> Input I think. The constants [15:06:04 CEST] <BBB> aha [15:06:06 CEST] <BBB> hm... [15:06:07 CEST] <J_Darnley> 16383 vas 16384 [15:06:08 CEST] <BBB> thats not good [15:06:13 CEST] <J_Darnley> and the 22k one [15:06:19 CEST] <BBB> well that would explain part of the problem [15:07:50 CEST] <J_Darnley> Oh, I mean the 19k one: 19265 vs 19266 [15:08:54 CEST] <BBB> I bet that if you change the constats, some other fate results break, but does it make the results more compliant? [15:09:00 CEST] <BBB> (for the mpeg/dct tests) [15:09:12 CEST] <J_Darnley> They do look closer, yes [15:14:46 CEST] <BBB> Im suspicious of the rounding [15:14:55 CEST] <BBB> if you need help, send me a patch and Ill see what I can do [15:14:57 CEST] <BBB> nice work so far :) [15:15:17 CEST] <J_Darnley> I will do that today. [15:15:47 CEST] <J_Darnley> Nice clean patches from the latest master. Not that horrible crap I showed you before. [15:17:04 CEST] <BBB> hehehehhe [15:17:14 CEST] <BBB> we all understand "wip" [15:17:58 CEST] <J_Darnley> Sigh. It does break fate. [15:18:09 CEST] <J_Darnley> I'll still make those patches [15:18:41 CEST] <BBB> of course it breaks fate, the prores dsp has different hardcoded coefficients [15:18:45 CEST] <BBB> Im not sure which are more correct [15:18:57 CEST] <BBB> we can make them different based on codec, thats not a terrible thing to do [15:47:17 CEST] <mateo`> ubitux: here are you result: http://sprunge.us/beTc [15:47:26 CEST] <ubitux> :(( [15:48:12 CEST] <jamrial> huh, that's weird [15:48:29 CEST] <ubitux> yeah :') [15:48:36 CEST] <jamrial> stereo_interpolate_neon that ubitux wrote looks exactly the same as the x86 one [15:48:40 CEST] <jamrial> it can't be slower than c... [15:48:53 CEST] <ubitux> is it faster on x86? :D [15:48:57 CEST] <nevcairiel> arm isnt x86, so maybe thats the problem :p [15:48:59 CEST] <ubitux> oh well, i can test that one :3 [15:49:06 CEST] <ubitux> it may be because of the stores [15:49:08 CEST] <ubitux> i need to profile [15:49:30 CEST] <jamrial> i know, but i'd expect the exact same vectorization to be faster than non vectorized c :p [15:50:57 CEST] <ubitux> stereo_interpolate_c: 28472.8 [15:50:58 CEST] <ubitux> stereo_interpolate_sse3: 13195.6 [15:51:00 CEST] <ubitux> stereo_interpolate_ipdopd_c: 27576.8 [15:51:02 CEST] <ubitux> stereo_interpolate_ipdopd_sse3: 12769.7 [15:51:04 CEST] <ubitux> x86 is indeed faster [15:51:19 CEST] <kierank> J_Darnley: nice [15:59:04 CEST] <ubitux> jamrial: isn't the stride missing an extend in ps hybrid analysis? (x86) [15:59:10 CEST] <ubitux> maybe we should change that to ptrdiff_t [15:59:18 CEST] <ubitux> i had to extend in the arm [16:00:35 CEST] <jamrial> ubitux: no, i did shl strided, which zero extends it implicitly [16:00:46 CEST] <ubitux> ah, interesting, ok [16:01:27 CEST] <jamrial> but yeah, changing it to prtdiff_t is a good idea in any case [16:10:08 CEST] <cone-651> ffmpeg 03James Almer 07master:b5a0971ff041: x86/aacps: add ff_ps_stereo_interpolate_ipdopd_sse3() [16:10:32 CEST] <jamrial> i forgot i hadn't push that [16:11:25 CEST] <atomnuker> jamrial: how much overall % did that improve aac decoding speed? [16:11:37 CEST] <ubitux> oh i'm an idiot i was testing the same function [16:11:47 CEST] <nevcairiel> you are hardpressed to even find a file that uses ipdopd :p [16:12:00 CEST] <jamrial> was going to say :p [16:12:22 CEST] <jamrial> there's like all of one sample that i knows uses it [16:14:03 CEST] <jamrial> ubitux: do you have a repo with the aacps checkasm tests you wrote? [16:14:19 CEST] <ubitux> yes, just a moment i'll push a fix for ipdopd [16:14:32 CEST] <jamrial> sure [16:15:01 CEST] <ubitux> aarch64-aac on github/ubitux/ffmpeg [16:15:43 CEST] <ubitux> note: it doesn't test exactness yet, but benchmarking works [16:16:00 CEST] <mateo`> ubitux: should i run the tests again ? [16:16:18 CEST] <ubitux> mateo`: sure, you can shame me as much as you want :3 [16:16:36 CEST] <ubitux> i'd love a perf record+report on the slow functions though [16:17:10 CEST] <mateo`> i thought you had a fix, anyway i'll do the record+report [16:17:15 CEST] <ubitux> jamrial: [16:17:17 CEST] <ubitux> ps_stereo_interpolate_c: 27760.5 [16:17:19 CEST] <ubitux> ps_stereo_interpolate_sse3: 13162.2 [16:17:21 CEST] <ubitux> ps_stereo_interpolate_ipdopd_c: 57883.0 [16:17:23 CEST] <ubitux> ps_stereo_interpolate_ipdopd_sse3: 21136.0 [16:17:45 CEST] <ubitux> mateo`: the "fix" was just about checking the correct function for ipdopd [16:26:32 CEST] <jamrial> ps_add_squares_sse: 4184.9 [16:26:33 CEST] <jamrial> ps_add_squares_sse3: 4183.8 [16:26:39 CEST] <jamrial> bah [16:27:01 CEST] <jamrial> so much for haddps :p [16:27:44 CEST] <Gramner> horizontal adds are slowš [16:28:34 CEST] <jamrial> i know, but this one was a case where haddps was perfect [16:28:38 CEST] <Gramner> haddps is essentially two shuffles and one addition on most cpus [16:29:21 CEST] <Gramner> no idea why they never bothered to optimize them. should've been trivial in hardware [16:29:55 CEST] <Gramner> instead they removed those instructions completely in EVEX [16:31:21 CEST] <Gramner> they're basically only useful for some slight code size reduction when they happen to do exactly what you want [16:40:10 CEST] <BBB> they removed them? [16:40:11 CEST] <BBB> bah [16:40:21 CEST] <BBB> I like hadds [16:40:29 CEST] <BBB> (in some situations) [16:41:05 CEST] <J_Darnley> Removed them? They now/will be illegal instructions? [16:50:30 CEST] <Prelude2004c> hey guys.. sorry didn't get answers in the regular channels. Does ffmpeg currently support key rotation for AES key ? I want to change up key say ever 1 hour without having to restart the transcoding. Is it as simple as just modifying the keyfile ? how does ffmpeg know to create new key entry in the m3u8 ? [16:56:07 CEST] <DHE> Prelude2004c: still not appropriate to ask in this channel [17:15:40 CEST] <ubitux> jamrial: moving the zips out of the loop helped [17:15:57 CEST] <ubitux> at least i'm faster now [17:16:20 CEST] <ubitux> so i basically replace 2 zip with 1 add in the inner loop [17:16:44 CEST] <ubitux> with the tradeoff of requiring one more reg, and 4 zip in the init [17:17:01 CEST] <ubitux> dunno if you do that already in the x86 [17:18:09 CEST] <Prelude2004c> Anyone here want to do a bit of dev. work with me on ffmpeg ? need an expert ffmpeg guy .. Message me privately. [17:18:27 CEST] <Prelude2004c> normally i work with UPWORK [17:19:58 CEST] <Gramner> J_Darnley: removed as in they don't have any EVEX-encoded version so you can't use them with zmm registers or with (x|y)mm16-31 [17:20:09 CEST] <Gramner> I'm more annoyed that they removed psign* [17:20:36 CEST] <Gramner> legacy versions will still work [17:25:48 CEST] <Gramner> fwiw google compute engine now have skylake xeons publically available if you want to do avx-512 stuff and don't have such a cpu of your own yet [17:27:42 CEST] <nevcairiel> i'm somewhat happy it appears they have avx512 in the skylake-x cpus, although apparently they were not quite clear yet if there is a avx512 unit per core or a central shared one [17:31:19 CEST] <DHE> I didn't know they were for sale yet... I thought they were still months out [17:31:31 CEST] <Gramner> doing off-core per-instruction computations would result in horrible latencies and is totally unfeasible [17:31:57 CEST] <Gramner> they're not for sale, but you can rent them as a cloud VM from google [17:32:07 CEST] <nevcairiel> yeah it sounded odd, but some people t hat otherwise seemed smart about such things said something to that effect [17:32:19 CEST] <nevcairiel> review NDA lifts next week, i think [17:32:36 CEST] <jamrial> ubitux: i don't, but just tried that and it's indeed faster :D [17:32:42 CEST] <ubitux> :) [17:32:59 CEST] <ubitux> i'm still slower on the ipodpdpdpd [17:33:11 CEST] <ubitux> but anyway, i'll dig that later [17:33:35 CEST] <Gramner> feel free to ask me whatever once the NDA ends. I've had one for months [17:36:30 CEST] <Gramner> although I think it's kind of silly to have NDA on things anyone can already rent and use. but I guess that's how it is [17:39:57 CEST] <atomnuker> that's just stupid [17:40:23 CEST] <atomnuker> what's to stop anyone from reviewing it anyway? not like they can trace it [17:40:51 CEST] <atomnuker> unless they encode serial number as an arbitrary 1-cycle delay on instructions [17:41:07 CEST] <nevcairiel> those people get free samples, and that would be the last time, so serious reviewers wouldnt [17:42:57 CEST] <atomnuker> wait, are they reviews for intel or reviews for normal people? [17:44:10 CEST] <nevcairiel> often it feels like the NDAs just exist to give everyone a decent chance to finish a decent review, instead of rushing half-assed things out to be the first to have it online [17:45:16 CEST] <atomnuker> does it take months to write a decent review? [17:45:41 CEST] <Gramner> afaik there's no NDA to what you can rent from google so you are free to run whatever benchmarks you want there. [17:45:54 CEST] <Gramner> reviewers dont have them for months [17:46:00 CEST] <Gramner> more like a week or so [17:46:18 CEST] <Gramner> although it can probably vary a lot from product to product [17:46:21 CEST] <nevcairiel> the xeons also dont really get that much reviewer attention then the consumer CPUs, ie. the skylake-x announced last week [17:48:27 CEST] <atomnuker> does amd do that? [17:48:43 CEST] <Gramner> well yeah, xeons are aimed at data centers and the people in charge of their purchasing decisions don't just buy whatever got good reviews in the latest magazine [17:49:47 CEST] <nevcairiel> as silly as it may be, datacenters are more likely to just blindly buy from spec sheets =p [19:19:56 CEST] <wm4> "This is a bug in the edit list fix index code. " hehe [19:20:12 CEST] <kierank> yeah big lol [19:20:25 CEST] <nevcairiel> just one? :) [20:05:46 CEST] <J_Darnley> Gramner: I see, thanks. (Re: horizontal adds) [20:16:41 CEST] <kevmark> <@BBB> kevmark: cehoyos will probably close it [20:16:46 CEST] <kevmark> Thanks for the heads up [20:27:43 CEST] <BBB> did he close it? [20:27:55 CEST] <BBB> kevmark: ^ [20:28:19 CEST] <kevmark> BBB, not yet, no [20:28:36 CEST] <BBB> whats the link? [20:28:38 CEST] <BBB> I can close it for you [20:28:40 CEST] <kevmark> https://trac.ffmpeg.org/ticket/5392 [20:28:50 CEST] <BBB> what commit fixed it? [20:29:10 CEST] <kevmark> michaelni asked for an accompanying fate test so perhaps cehoyos is waiting on that? [20:29:21 CEST] <BBB> no, the bug tracker is just for bugs [20:29:33 CEST] <BBB> I mean, I agree a fate test would be a good idea [20:29:39 CEST] <kevmark> 3385989b98be7940044e4f0a6b431a0a00abf2fa https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/3385989b98be7940044e4f0a6b4… [20:29:42 CEST] <BBB> but if the bug is fixed in and by itself, the bug should be closed [20:30:20 CEST] <michaelni> kevmark, i can add you to the list of developer n trac then you can close it yourself [20:30:28 CEST] <michaelni> also anyone else that needs to be added ? [20:30:31 CEST] <BBB> I already closed it [20:30:31 CEST] <kevmark> Gotcha. There was a short discussion in the patch thread about if the behavior was truly a "bug" or not, but at this point it's not much of an issue [20:30:49 CEST] <BBB> but if he wants to be added Im fine with that also [20:31:19 CEST] Action: BBB kicks fflogger [20:31:29 CEST] <BBB> kinda slow today... [20:31:58 CEST] <kevmark> michaelni, sure, I'd have no issue with that [20:32:04 CEST] <kevmark> Register first? [20:32:27 CEST] <kevmark> Nice anti spam filter [20:32:57 CEST] <michaelni> long ago i remember going over all user accounts and added everyone i recognized as having contributed but i think the number of accounts is a bit large these days [20:34:04 CEST] <kevmark> GitHub claims 883 total contributors on the project [20:34:07 CEST] <kevmark> Username is kmark [20:36:24 CEST] <michaelni> kevmark, added [20:36:28 CEST] <kevmark> ty [20:37:44 CEST] <kevmark> I respect that you give developer permissions on the tracker to those who contribute. I've always been wary to do that myself. [20:38:35 CEST] <michaelni> ffmpeg trac has 4899 registered users btw [20:41:23 CEST] <kevmark> That's pretty good although I'm not too surprised since you need an account there to add a ticket [21:10:26 CEST] <philipl> BtbN: fix for bframes seems obvious in retrospect. [21:12:24 CEST] <BtbN> well, they don't have a context bound there in any of their own examples [21:15:58 CEST] <philipl> Yeah. They were very unclear about context usage. [21:16:33 CEST] <BtbN> this could also have been settles within a single mail of them telling us to bind a context [21:17:03 CEST] <BtbN> Also, not entirely happy with the patch, it looks rather uggly. With that many calls, it almost needs a wrapper [21:17:17 CEST] <BtbN> it's always the same few lines, could just be a mcro [21:17:20 CEST] <BtbN> *macro [21:17:44 CEST] <BtbN> Anyway, going to apply it as-is, and fix that later. [21:23:46 CEST] <BtbN> philipl, also, I don't understand how this happened to work before the change of the initialization order [21:23:53 CEST] <BtbN> I confirmed multiple times that no CUDA context leaks [21:24:03 CEST] <BtbN> it also works with frames supplied by hwupload_cuda [21:37:27 CEST] <cone-651> ffmpeg 03Ganapathy Kasi 07master:43c417ac1adb: avcodec/nvenc: fix hw accelerated transcode with bframes [21:50:53 CEST] <cone-651> ffmpeg 03Ganapathy Kasi 07release/3.3:9b351d0d888d: avcodec/nvenc: fix hw accelerated transcode with bframes [21:51:44 CEST] <philipl> BtbN: undefined behaviour working out in our favour [00:00:00 CEST] --- Sat Jun 3 2017

1 0

ffmpeg.log.20170602
by burek 03 Jun '17

03 Jun '17

[00:12:14 CEST] <ac_slater_> ugh guys! Timestamps/timebases ... [00:13:14 CEST] <ac_slater_> when I do `ffprobe -show_streams` on an mpegts file, the timebase for EACH stream (h264 and another is just raw data), it shows they both have a 1/90000 timebase. Even though I set the raw data stream to 1/15 [00:13:50 CEST] <ac_slater_> what's happening there [00:15:22 CEST] <furq> mpegts always has a timebase of 1/90000 [00:15:49 CEST] <ac_slater_> I wish I could get that timebase from the AVFormatContext ... [00:15:58 CEST] <ac_slater_> but it just is no where to be found [00:16:10 CEST] <furq> you don't need to [00:16:12 CEST] <furq> it's 1/90000 [00:16:17 CEST] <ac_slater_> I mean, I know the constant [00:16:26 CEST] <ac_slater_> it just makes it hard to write generic muxer interfaces :p [00:16:42 CEST] <ac_slater_> I would think that AVFormatContext would carry around the muxer/demuxer timebase [00:19:28 CEST] <furq> https://ffmpeg.org/doxygen/trunk/structAVStream.html#a9db755451f14e2bf590d4… [00:19:41 CEST] <furq> In avformat_write_header(), the muxer will overwrite this field with the timebase that will actually be used for the timestamps written into the file (which may or may not be related to the user-provided one, depending on the format). [00:22:20 CEST] <JodaZ> anyone got me a hail mary commandline to fix timestamps/seeking? [00:36:48 CEST] <ac_slater_> furq: awesome! [02:10:54 CEST] <sea> http://sprunge.us/NcJX <- What's the explanation for this odd behavior? [02:11:36 CEST] <sea> Somehow, ffmpeg removes characters from stdin [02:12:16 CEST] <c_14> add -nostdin [02:12:40 CEST] <sea> AhA! brilliant. [02:12:59 CEST] <sea> ..should it really be eating a character when that's not supplied though? I gave it -y [02:13:15 CEST] <c_14> ffmpeg supports certain commands on stdin [02:13:56 CEST] <sea> I notice it eats the b, but not really any other character. I guess b is a command of some kind [02:14:07 CEST] <sea> Okay it makes sense then. [03:33:21 CEST] <ac_slater_> quit [03:33:23 CEST] <ac_slater_> sorry! [03:33:25 CEST] <ac_slater_> quit [03:33:27 CEST] <ac_slater_> fuuuu [03:33:32 CEST] <furq> bye [03:34:09 CEST] <furq> there's probably a "saved by the bell" joke i could've made there, but i don't remember anything anyone said in that show [03:37:22 CEST] <johnjay> hey furq, sup [03:37:46 CEST] <johnjay> do you know why i can't install ffmpeg on my rpi? [03:55:18 CEST] <petecouture> johnjay what error do you get when you build it? [03:59:11 CEST] <johnjay> petecouture: I meant literally install as in, apt-get install ffmpeg fails [03:59:20 CEST] <johnjay> i haven't tried compiling it myself [03:59:40 CEST] <DHE> then that's a debian/ubuntu/whatever fault [04:00:11 CEST] <johnjay> ah ok. i thought maybe since i'm on a rpi maybe there's a problem with getting ffmpeg to work on it [04:00:55 CEST] <furq> probably because your distro is still running debian jessie, which is still on libav [04:01:17 CEST] <furq> the ffmpeg from repos would be useless on rpi though because it doesn't have omx or mmal [04:03:34 CEST] <DHE> I wouldn't want software decoding/encoding on a Pi... [04:12:04 CEST] <johnjay> furq: ah ok I didn't realize that fork thing was still relevant even in jessie [04:13:00 CEST] <furq> well jessie is over two years old now [04:13:10 CEST] <furq> stretch is coming out any day now [04:13:39 CEST] <furq> then we'll never have to worry about this ever again, he lied [04:14:04 CEST] <johnjay> lol speaking of forks I read about something with mplayer [04:14:20 CEST] <johnjay> when I tried to apt-get install mplayer it said "warning selecting mplayer2 because that other one is deprecated" [04:14:32 CEST] <johnjay> and I was like what so I googled and it was the same thing, mplayer2 is a dead fork [04:15:03 CEST] <furq> this is why you shouldn't use a stable distro [04:16:16 CEST] <DHE> mpv is the new hotness anyway.... [04:16:24 CEST] <furq> also yeah this is why you shouldn't use mplayer [04:16:31 CEST] <johnjay> lol apparently i was foolishly trying to though [04:16:35 CEST] <DHE> and I say "new" relative to people who are asking for mplayer in the first place. :) [04:17:16 CEST] <johnjay> well once you go sid you can never go back [04:17:23 CEST] <johnjay> so maybe i'll use a different sd card for that [04:17:35 CEST] <furq> i went sid and went back [04:17:39 CEST] <furq> testing for life [04:47:42 CEST] <k_sze[work]> Does anyone know whether the JPEG standard specify maximum sizes for the quantization and Huffman tables? Apparently the (Huffman) table size can vary, with optimization like jpegmini. [04:47:51 CEST] <JEEB> .2 [04:51:32 CEST] <johnjay> I did google a bit before hand though [04:51:48 CEST] <johnjay> I randomly found someone on the mailing list talking about a patch for ffmpeg on the rpi [04:52:07 CEST] <johnjay> something about using hand coded assembly is always better and gcc problems with FATE [04:56:55 CEST] <johnjay> btw it's odd you say rpi doesn't have mmal. when I googled for it it says mmal is specificall designed for the videocore which the pi has [05:00:06 CEST] <furq> i didn't say that [05:00:13 CEST] <furq> i said the ffmpeg builds in the debian repos don't have mmal enabled [05:00:35 CEST] <johnjay> oh [05:01:08 CEST] <johnjay> based on my experience compiling hostapd yesterday to make my pi into an AP [05:01:14 CEST] <johnjay> those distro ppl must have a lot of work though [05:01:19 CEST] <johnjay> you have to compile... everything [05:01:59 CEST] <furq> well they have scripts and build farms for all that [05:02:36 CEST] <tdr> or just cross compile it on a beefy box [05:03:08 CEST] <johnjay> sounds like a nightmare. but i guess if you have scripts and beef then it's fine [05:03:43 CEST] <tdr> its steps to setup but not super hard, just alot of checks and testing [05:04:08 CEST] <tdr> cross compiling now is a lot easier than say 10 yrs ago [05:04:16 CEST] <furq> it's piss easy if you have a debian testing box [05:04:19 CEST] <furq> or a recent ubuntu [05:04:51 CEST] <furq> the armhf toolchain is part of the repos now, plus you can just install all the deps with multiarch [05:05:09 CEST] <furq> apparently it's similarly easy on fedora but i don't touch rpm [05:07:38 CEST] <johnjay> furq: maybe i'll learn how to do it. for now i'm stuck with this pi until I get a new fan for my PC [05:07:56 CEST] <johnjay> so i tried installing ffmpeg naturally and wondered why it failed [05:11:35 CEST] <tdr> how did you install? [05:11:50 CEST] <tdr> could be missing deps or be build against different library versions [05:12:33 CEST] <johnjay> tdr: though apt-get. apparently jessie still has libav according to furq [05:13:03 CEST] <johnjay> but yeah that's a thing too. I tried installing an n64 emulator and I got a message about the package not existing but another package depends on it [05:38:35 CEST] <tdr> johnjay, check the location where it added the files. it could be somewhere "odd" [05:39:59 CEST] <johnjay> tdr: the n64 thing? on apt-get it refuses to download if it doesn't satisfy dependencies [05:40:04 CEST] <johnjay> although there's a way to force it [05:40:14 CEST] <furq> have you been mixing and matching repos [05:40:35 CEST] <furq> granted i wouldn't expect a pi to be able to passably emulate an n64 [05:41:26 CEST] <johnjay> furq: more like distros. I have raspbian on this card and retropi on the other one [05:41:49 CEST] <furq> i meant within one distro [05:42:04 CEST] <furq> apt shouldn't be throwing dependency errors unless you have unofficial repos or something [05:42:13 CEST] <johnjay> nope. but am I to understand that running testing is a better option than mixing and matching repos? [05:42:27 CEST] <furq> testing is generally just better [05:42:42 CEST] <johnjay> well maybe i misspoke. it just said that the package didn't exist but was referred to by another package [05:42:48 CEST] <furq> mixing and matching official repos is a surefire way to end up in hell [05:42:49 CEST] <johnjay> some kind of n64 mulator called mupen64plus [05:43:20 CEST] <furq> that's amd64 and i386 only [05:43:24 CEST] <furq> so no wonder it doesn't exist [05:44:29 CEST] <furq> https://www.libretro.com/index.php/retroarch-2/ [05:44:32 CEST] <furq> you probably want that anyway [05:50:43 CEST] <johnjay> i think I searched all the names [05:50:49 CEST] <johnjay> retroarch, retropi, emulation [05:51:29 CEST] <furq> retroarch isn't in the debian repos but they provide deb packages iirc [05:51:49 CEST] <furq> i've got it running on testing on my laptop, so you should be able to massage it into working [05:53:26 CEST] <johnjay> i'm trying to follow these rules [05:53:38 CEST] <johnjay> so mixing and matching repos is bad. testing is good. downloading .debs is ok [05:53:48 CEST] <furq> yup [05:53:59 CEST] <furq> downloading debs is fine because it'll either work or it won't [05:54:38 CEST] <furq> mixing and matching repos is not fine because it'll download some dependency from the unofficial repo that ends up causing unresolvable dependency issues two months later [05:55:05 CEST] <furq> now the manually installed deb might also break two months later, but it can only really break itself [05:56:15 CEST] <johnjay> like you download package2.7 and later find out you have to have package2.8 in 2 months and it's not allowed to have both? [05:58:29 CEST] <furq> like package1 depends on libdep > 2.0 and < 2.1, package2 depends on libdep 2.1, then package1 gets updated and now it depends on libdep 2.2 [05:59:08 CEST] <furq> imagine that except with a thousand packages which potentially have 100 dependencies [06:00:09 CEST] <furq> you'd think i would have either used numerals or words for both of those numbers. don't be silly [06:02:33 CEST] <johnjay> yeah sounds horrible [06:02:43 CEST] <johnjay> i don't like having to use packages in the first place but i guess it's better than the alternative [06:09:19 CEST] <johnjay> by the way why don't you think the pi can emulate an n64? [06:09:39 CEST] <johnjay> idk how you would estimate something like that [06:14:41 CEST] <furq> because i know it struggles with the psx [06:15:02 CEST] <furq> even an overclocked pi 3 has difficulty with 3d consoles [06:15:13 CEST] <furq> and n64 emulation was much less mature than psx last i checked [06:15:28 CEST] <furq> not that i care, i never had one [06:20:33 CEST] <johnjay> interesting, i thought it would have come along since the days of UltraHLE [08:23:48 CEST] <ac_slater> guys, when I do the following on the command line, `ffmpeg -i whatever -f mpegts -f rtp udp://0.0.0.0:9999`, what kind of AVFormat muxer chain is being constructed? I know it creates both mpegts and rtp muxers, but how are they bound via AVFormatContexts? [08:24:15 CEST] <ac_slater> I guess, how do I bind two AVOutputContexts [08:24:17 CEST] <ac_slater> ? [08:29:33 CEST] <ac_slater> I guess I should just breakpoint the hell out of the command line app [08:33:24 CEST] <ac_slater> maybe I'm really binding and output to an input at that point... [08:34:14 CEST] <ac_slater> or stream really. I think I got it [08:51:50 CEST] <kerio> how do i downsample from 96khz to 48khz [08:52:01 CEST] <furq> -ar 48000 [08:53:22 CEST] <furq> or -af aresample=resampler=soxr if ya nasty [08:53:30 CEST] <furq> er [08:53:40 CEST] <furq> -af aresample=48000:resampler=soxr [08:53:56 CEST] <kerio> will -ar use sox [08:54:00 CEST] <furq> no [08:54:03 CEST] <kerio> :< [08:54:04 CEST] <furq> also you need a build with --enable-sox [08:54:17 CEST] <furq> i think you can do -ar 48000 -resampler soxr [08:54:35 CEST] <furq> i'm pretty sure that just uses aresample [08:54:48 CEST] <kerio> Requested resampling engine is unavailable 😭 [08:55:02 CEST] <furq> rip [08:55:24 CEST] <furq> sox's resampler was much better than ffmpeg's at the time the site that did comparisons made their nice images [08:55:28 CEST] <furq> but that was with ffmpeg 1.1 [08:55:41 CEST] <furq> i have no idea whether it's worth it any more [08:56:17 CEST] <furq> i'm sure durandal_1707 will be along shortly to make explicit threats against my life for suggesting that sox is any good [08:58:37 CEST] <kerio> anyway new radiohead ;o [08:58:41 CEST] <kerio> it's actually old radiohead tho ;o [09:04:37 CEST] <durandal_1707> furq: same images can be made with ffmpeg resampler, it just have bad defaults [09:04:55 CEST] <furq> why doesn't it have good defaults [09:05:44 CEST] <durandal_1707> complain to michaelni, he needs proof that when listening to it one can hear difference [09:06:36 CEST] <furq> so what are the good settings for swresample then [09:06:51 CEST] <ac_slater> something I always wished existed within ffmpeg is a filtergraph capable of showing stuff like streaming loss or a decoding timeline including malformed input [09:07:02 CEST] <ac_slater> so like, you can see in realtime some decoding visuals [09:07:05 CEST] <ac_slater> would be cool [09:07:10 CEST] <ac_slater> anyway, carry on [09:07:54 CEST] <durandal_1707> furq: search mailing list for topic [09:08:15 CEST] <furq> i don't care that much, i don't have anything above 48khz anyway [09:09:46 CEST] <furq> maybe if someone was on irc asking how to downsample some good music that is worth listening to, i would check [09:09:49 CEST] <furq> but that has never happened [09:10:14 CEST] <ac_slater> so, If I wanted to emulate the `-f mpegts -f rtp ...` command line via libavformat, would I construct the mpegts to be an output format (avformat_alloc_output_context2) and the rtp be an input context via avformat_open_input? [09:10:20 CEST] <furq> is that even a thing [09:11:05 CEST] <ac_slater> ? [09:11:27 CEST] <furq> i'm pretty sure that's just -f rtp [09:11:35 CEST] <ac_slater> hmm maybe [09:11:44 CEST] <ac_slater> but it does do the right thing [09:11:57 CEST] <furq> i assume you want rtp_mpegts for mpegts over rtp [09:12:40 CEST] <ac_slater> wait [09:12:44 CEST] <ac_slater> wtf is rtp_mpegts [09:13:10 CEST] <kerio> furq: >:c [09:13:38 CEST] <ac_slater> furq: the docs for rtp_mpegts are basically non existant [09:13:49 CEST] <furq> that sounds about right [09:13:55 CEST] <ac_slater> ;) [09:14:43 CEST] <ac_slater> but either way furq I'm a little puzzle on how to take an AVFormatContext I alloc'ed with avformat_alloc_output_context2 (ie - an output context), and tell it to send somewhere else rather than it's default [09:15:06 CEST] <ac_slater> I can do it with context->pb if I wanted to override it with avio manually... but it should be easy to "chain" these things right? [09:18:21 CEST] <ac_slater> it's actually really bothering me that I cant seem to figure it out [09:19:38 CEST] <ac_slater> furq: you're my only hope [09:49:05 CEST] <ac_slater> furq: well... jeeze rtp_mpegts should be documented [09:49:22 CEST] <ac_slater> it's weird how it doesnt spit out an sdp file or anything ... like it's a special thing [09:50:17 CEST] <ac_slater> I cant even find which encoder/format source files it belongs to [09:50:29 CEST] <ac_slater> oh I did find it [09:50:34 CEST] <ac_slater> but wtf seriously [09:50:53 CEST] <ac_slater> wouldnt `-f mpegts -f rtp` make more sense? [10:06:41 CEST] <ac_slater> I'm going to make a small assertion here to say that it's near impossible to easily "chain" a muxer with another muxer [10:08:21 CEST] <ac_slater> I just dont think it's supported [10:35:07 CEST] <ac_slater> eeek getting a SIGBUS on av_packet_free_side_data [11:25:02 CEST] <zerodefect> I'm generating a mpeg2video wrapped in a TS. Can you suggest a tool/method to determine if my video contains B-frames. MediaInfo says N=1. Does that indicate intra-only? [14:25:15 CEST] <eightfold> it is a known problem that video filmed with many mobiles have variable frame rates (vfr). most solutions involve transcoding to cfr and h.264 using handbrake. [14:25:48 CEST] <eightfold> i should also add that this results in audio desync in premiere, which is why people editing video transcodes in the first place... [14:27:20 CEST] <eightfold> i would like to transcode from the mobile vfr files to prores cfr files. does anybody know if theres a switch i could use to make the audio and video stay in sync? [15:18:49 CEST] <thebombzen> eightfold: if you transcode with ffmpeg it'll handle VFR properly [15:19:24 CEST] <eightfold> thebombzen: hmm, ill have to give it a spin. last time i tried video and audio was out of sync. [15:19:34 CEST] <thebombzen> last time you tried it with handbrake? [15:20:12 CEST] <thebombzen> just use ffmpeg directly. try this: ffmpeg -i input.mp4 -c:v prores -c:a copy -vsync cfr output.mov [15:20:30 CEST] <thebombzen> you might want to set a bitrate with -b:v <bitrate> [15:20:46 CEST] <thebombzen> otherwise it'll default to something *really low* [15:28:28 CEST] <nelder> hello all, i have this error "[ffmpeg] https: the user-agent option is deprecated, please use user_agent option". why? [15:29:15 CEST] <nelder> how i can use user_agent, where it may be pasted? [15:31:40 CEST] <thebombzen> nelder: you probably have something that's setting -user-agent [15:31:41 CEST] <thebombzen> don't do that [15:32:21 CEST] <thebombzen> nelder: I'm guessing you probably wouldn't be asking this quesiton if you didn't have "user-agent" on the actual command line [15:33:58 CEST] <JonnyG> Hi everyone [15:34:04 CEST] <nelder> well, i just want to see youtube online videos with mpv (it uses ffmpeg) and after i type at console #mpv <some link> i see this error [15:35:13 CEST] <JonnyG> Sorry to disturb you, just wanted to know if someone knows about iOS, or could help me on an issue. I cannot add any audio to an mp4 video [15:35:33 CEST] <JonnyG> Not sure if the video is not supported by iOS, but I don't see anything wrong with it [15:35:35 CEST] <thebombzen> nelder: I don't recommend running mpv as root [15:35:39 CEST] <thebombzen> you have no reason to do that [15:35:50 CEST] <thebombzen> nelder: you probably have an environment variable issue. either way, I'd ask in #mpv rather than #ffmpeg [15:36:02 CEST] <nelder> thebombzen: i use only user console for it [15:36:20 CEST] <thebombzen> nelder: then don't say: # mpv <some link> [15:36:25 CEST] <thebombzen> that implies you're running it as root [15:36:40 CEST] <thebombzen> JonnyG: some audio codecs like ALAC need -f ipod [15:36:53 CEST] <thebombzen> that is if you want to put them inside an mp4 container like .m4a with ALAC [15:37:24 CEST] <thebombzen> JonnyG: If you use `-f ipod` then FFmpeg will use a special case of the mp4 muxer that's Apple-Compatible [15:37:39 CEST] <nelder> http://dpaste.com/1RJ467K [15:37:53 CEST] <nelder> ^^^ this all that i see [15:38:00 CEST] <thebombzen> what version of ffmpeg do you have? [15:38:18 CEST] <thebombzen> and what version of mpv? It sounds like there's some old versions clashing b/c of deprecated stuff [15:38:35 CEST] <nelder> 3.2.4 [15:38:39 CEST] <thebombzen> also you need to have youtube-dl in your path to make that work [15:38:44 CEST] <JonnyG> thebombzen : Thanks for the infos ! Actually the mp4 video doesnt have an audio track, and I want to add an AAC track. I can add the AAC to track to many other videos, but I iOS give me an error when I add it to this particular video [15:39:13 CEST] <thebombzen> JonnyG: well iOS isn't adding audio, so what is your command that produces a file that iOS complains about? [15:39:58 CEST] <thebombzen> nelder: what happens if you run: youtube-dl -g 'https://youtu.be/CmELf8DJAVY' [15:40:27 CEST] <nelder> versions -> http://dpaste.com/2HSG69R [15:40:42 CEST] <thebombzen> that mpv is very old [15:40:43 CEST] <thebombzen> update it [15:41:33 CEST] <thebombzen> youtube-dl is also a few months. youtube-dl is constantly being updated to keep up with YouTube's internal changes and to unbreak videos that used to work, so keep that in mind as well. I recommend updating youtube-dl [15:41:38 CEST] <nelder> youtube-dl -> http://dpaste.com/1DH5R79 [15:41:53 CEST] <thebombzen> update your youtube-dl as well [15:42:02 CEST] <nelder> eh... i see [15:42:09 CEST] <thebombzen> it works with 2017-05-29 [15:42:41 CEST] <thebombzen> in fact, it even tells this to you on the error message: Make sure you are using the latest version; see https://yt-dl.org/update on how to update. [15:44:09 CEST] <thebombzen> nelder: what distro are you using? because if you're on an LTS distro that doesn't update its packages regularly, I'd recommend building some of these from source, like mpv or [15:44:36 CEST] <nelder> i use gentoo [15:44:49 CEST] <thebombzen> well then you have no excuse not to have your packages updated ^_^ [15:45:02 CEST] <JonnyG> thebombzen, fflogger : I'm using an iOS official SDK (AVFoundation), to add audio. I don't use ffmpeg so I don't have ffmpeg commands [15:45:19 CEST] <JonnyG> But I thought maybe you guys know why this particular video doesnt work [15:45:26 CEST] <JonnyG> maybe it's corrupted or something [15:45:33 CEST] <nelder> ) [15:45:33 CEST] <JonnyG> could I send you a link the video (dropbox) >? [15:45:48 CEST] <thebombzen> JonnyG: this is the ffmpeg help channel, so if AVFoundation fails at doing something, I'm going to tell you to use FFmpeg to do the same thing [15:46:21 CEST] <thebombzen> I cannot possible answer why something that isn't related to FFmpeg doesn't work. I dont' really want a dropbox link, I recommend just using FFmpeg [15:46:24 CEST] <JonnyG> Of course, I use ffmpeg to do the same thing on Android, but it's hard to use ffmpeg on iOS ;) [15:46:39 CEST] <thebombzen> are you trying to create the video *on* the phone? [15:46:44 CEST] <JonnyG> because command lines are not accepted from a program [15:47:06 CEST] <JonnyG> I could use the ffmpeg C api [15:47:09 CEST] <thebombzen> Execv is sandboxed I believe, but you could always bundle libavcodec and libavformat yea [15:47:13 CEST] <JonnyG> but I have no idea how it works [15:47:27 CEST] <thebombzen> if you're a developer dealing with audio/video it's a good investment to learn how it works [15:47:38 CEST] <thebombzen> I don't actually know but there's some examples somewhere [16:01:22 CEST] <eightfold> thebombzen: no, last time i tried with ffmpeg [16:01:43 CEST] <eightfold> Ill try that line, thanks [16:05:24 CEST] <thebombzen> the -vsync cfr does what you probably think it does... force cfr. Alternatively, you could use -r or -vf fps if you need to force a very particular framerate [16:05:30 CEST] <thebombzen> otherwise it'll use the average framerate of the input [16:06:03 CEST] <eightfold> thebombzen: trying now. it spits out a lot of these: Past duration 0.710045 too large 1278609kB time=00:00:19.07 bitrate=549071.1kbits/s dup=9 drop=0 speed=0.251x [16:06:39 CEST] <eightfold> i need to force a particular framerate [16:06:48 CEST] <eightfold> 25 fps [16:07:09 CEST] <eightfold> should i just add -vf 25 [16:07:16 CEST] <eightfold> to the exact line you gave above? [16:09:04 CEST] <eightfold> thebombzen: obiously not, i got [AVFilterGraph @ 0x7f7ffa415580] No such filter: '25' [16:09:05 CEST] <eightfold> :) [16:09:21 CEST] <thebombzen> -vf fps means use the fps filter [16:09:25 CEST] <thebombzen> -vf fps=25 [16:12:09 CEST] <eightfold> thebombzen: thanks! is this something something i should care about: [swscaler @ 0x7fafa304a800] deprecated pixel format used, make sure you did set range correctly [16:23:45 CEST] <ac_slater> when I open an AVFormatContext (input or output), does specifying an output file like udp://0.0.0.0:9999?pkt_size=752 actually pass pkt_size = 752 to the udp output format? [16:24:19 CEST] <thebombzen> eightfold: that means it probably is "yuvj444p" or "yuvj420p" [16:24:28 CEST] <thebombzen> that means fullrange rather than partial [16:24:48 CEST] <thebombzen> however it's required for mjpeg and perhaps prores so I don't know. it can be safely ignored and it's kind of annoying [16:25:17 CEST] <thebombzen> ac_slater: I believe that libavformat will handle the URL [16:25:24 CEST] <thebombzen> including the params [16:25:28 CEST] <thebombzen> you mgith want to doublecheck that though [16:25:36 CEST] <ac_slater> thebombzen: yea I will [16:25:49 CEST] <ac_slater> I just dont see another way to pass a dict of options to a explicit demuxer [16:26:22 CEST] <ac_slater> like calling avformat_alloc_output2 (or whatever it is) creates an output context [16:26:31 CEST] <ac_slater> but no real way to craft a dict ahead of time and pass it in [16:26:40 CEST] <ac_slater> unless the "metadata" field is that [16:27:02 CEST] <eightfold> thebombzen: audio and video is in sync! awesome, thanks [16:28:05 CEST] <thebombzen> I doubt it [16:28:16 CEST] <thebombzen> this might go under "just try it, I guess?" [16:28:22 CEST] <ac_slater> yea [16:28:24 CEST] <ac_slater> thanks mate! [16:28:31 CEST] <eightfold> thebombzen: and no, the default bitrate for prores does not seem to be low. 10,2 gb for 2 minutes of 4k video :) [16:39:49 CEST] <thebombzen> usually ffmpeg defaults to 200k or 2000k I think. perhaps prores is different? idk [16:42:49 CEST] <Prelude2004c> hey everyone good day. I am doing HLS with AES encryption. Does FFMPEG currently support key rotation ? [16:43:07 CEST] <Prelude2004c> Do i simply just need to replace the key file but then how does the m3u8 know to insert new key ? [16:55:47 CEST] <DHE> Prelude2004c: replace the whole keyinfo file atomically [16:57:22 CEST] <Prelude2004c> thank you DHE, so if i just replace the whole key file with a new one, the HLS m3u8 will automatically be modified ? [17:02:50 CEST] <DHE> when new .ts files are made the keyinfo is re-read [17:03:17 CEST] <Prelude2004c> ahh it looks like it works :0 fantastic [17:04:36 CEST] <Prelude2004c> last question that you may be able to help.. in the shell script that i built i am generting a key then strarting ffmpeg.... how do i put the key on say a 1 hour rotation.. do i just put a while 1; do < key commands > ; sleep 3600 ; done ... but how do i then continue while running that in background .. like do i just add something like && at the end of done so the script keeps executing while the loop for the key keeps generating ? [17:05:39 CEST] <DHE> that's shell scripting... you can run a while command in the background with & like you would any other shell command by placing it after the word 'done' [17:06:38 CEST] <Prelude2004c> ok... that makes sense.. only problem is... what happens if i kill the script.. does the & stay running.. just a question i can ask in #bash but maybe your more savvy about that sort of thing [17:09:49 CEST] <DHE> no, that is definitely a #bash thing [17:09:51 CEST] <DHE> :) [17:16:40 CEST] <Prelude2004c> ok.. so you know.. i just put whole thing in a screen and then put the & at the end and it works like a charm.. thank you [17:16:54 CEST] <Prelude2004c> funny, there isn't very much documentation online about key rotation .. very odd :) .. DHE, thank you again [18:36:45 CEST] <ChocolateArmpits> Does anyone know if multiple outputs have frames get written to output at the same time even if one of the encoders buffers longer ? [18:40:31 CEST] <ChocolateArmpits> I'm testing for encoder+network+decoding latency. One of the outputs encodes and sends the frames over network, other output gets piped to ffplay to be compared with the prepared first stream. I fear this may be flawed and not have encoding latency in check [18:43:53 CEST] <c_14> I'm pretty sure they're written sequentially [19:02:53 CEST] <Papi> Hello [19:03:35 CEST] <Papi> I am using with ffmpeg -i parameter. Can be ffmpeg stopped automatically when no data incoming throught given URL? It cause only problems when rtmp stream ends and ffmpeg is still running... [19:04:28 CEST] <ChocolateArmpits> Papi, check timeout setting in the docs [19:05:54 CEST] <Papi> Timeout won't help me. Because it's for rtmp stream in livestream service [19:12:44 CEST] <Papi> Does anoyone know? [19:12:48 CEST] <Papi> *anyone [19:14:08 CEST] <zerodefect> I'm trying to generate an MPEG2 SD video stream @ 25fps with it all being wrapped in TS from within my own application using the C-API. At the moment, it all works well. I can view the video in ffplay. The problem I have at the moment, is that I can seem to get b frames working. I've set 'gop_size' to 12 and 'max_b_frames' to 2 in the AVCodecContext. Are there any other settings I should [19:14:08 CEST] <zerodefect> tweak? [19:14:47 CEST] <ChocolateArmpits> Papi, check -progress and if there's no incoming data kill the process [19:15:31 CEST] <BtbN> zerodefect, -bf? [19:15:44 CEST] <BtbN> But I think that maps to max_b_frames [19:17:40 CEST] <Papi> I thought ffmpeg can do it automatically. With ur solution I have to pair PID with correct streamer [19:17:44 CEST] <zerodefect> Okay, thanks for the tip. I'll see what the source does with the mapping. Is a value of 2 a valid value? [19:19:24 CEST] <zerodefect> Is explicitly setting the profile or level required? [19:20:17 CEST] <kepstin> zerodefect: I don't think there are any profile/level options in the mpeg1/2 encoder? [19:20:42 CEST] <Papi> Only full output settings is required. I am using ffmpeg for transcoding [19:20:51 CEST] <kepstin> make sure you don't have any 'low latency' flags enabled, those obviously would disable b-frames. [19:22:25 CEST] <Papi> Here's part of my command... ffmpeg -i rtmp://localhost:1935/$1/$2 -vcodec libx264 -vprofile high -preset ultrafast -x264opts keyint=40 -vf scale=640x360 -minrate 600k -maxrate 800k -acodec aac -strict -2 -f flv rtmp://localhost:1935/hls/$STREAM_NAME_low [19:22:41 CEST] <zerodefect> kepstin: Ok. I'll double check. Thanks [19:29:12 CEST] <zerodefect> kepstin: There is a 'profile' and 'level' field in the AVCodecContext --> http://ffmpeg.org/doxygen/trunk/structAVCodecContext.html [19:32:57 CEST] <kepstin> looks like in mpeg12enc it's just used to put a number in the header, and doesn't actually do anything to the video itself [19:35:29 CEST] <zerodefect> Yeah, that is what I thought. It is why I hadn't set it. [19:35:36 CEST] <zerodefect> I guess the other point is that MediaInfo says that 'N=1' for my GOP structure. Can I trust it? [19:37:59 CEST] <Papi> Is here some1 who can help me with my problem? [19:39:16 CEST] <Mista-D> force_key_frames every 90th frame ? can't use "-g 90". [19:41:24 CEST] <Papi> How forcing key frame can help me? [19:43:22 CEST] <Papi> hm? [19:43:34 CEST] <Papi> @Mista-D [19:45:32 CEST] <Mista-D> Papi: I'd like to know how to force keyframe every 90 frames instread of using "g 90". [19:46:13 CEST] <Papi> Ah... I thought that was react to my questing [19:46:16 CEST] <Papi> *question [19:46:45 CEST] <Mista-D> As per your problem, I'd look into using vlc as live transcoder - it can have a playlist input, when live stream ends it switches to next item (a looped video, static image, etc) [19:51:38 CEST] <Papi> I need to kill ffmpeg process when rtmp stream ends, because this "sleeping" ffmpeg processes consume RAM and causing problems [19:52:21 CEST] <Mista-D> -xerror ?? [19:52:24 CEST] <Papi> Cause error in ffmpeg that will cause drop of ffmpeg is also solution for me [19:52:51 CEST] <Papi> I'll try [19:54:26 CEST] <Papi> Doesn't work :/ [19:55:03 CEST] <Papi> It seems empty rtmp stream won't cause error [20:04:31 CEST] <zerodefect> kepstin:Is there more than one mp2v encoder? Could I be using a version that doesn't support b frames? [20:05:00 CEST] <kepstin> zerodefect: ffmpeg only has one supported mpeg2 video encoder, the built-in one, and it does b-frames just fine. [20:05:48 CEST] <zerodefect> I'll keep digging :) [20:08:35 CEST] <kepstin> with the default b frame strategy, it should just be using the 'max_bframes' value as-is and encoding that many b-frames every time (aside from the end of gop, when there's sometimes weird behaviour) [20:20:08 CEST] <Papi> I can't believe my problem has no solution [20:20:09 CEST] <zerodefect> Yeah, the examples are pretty easy to follow, but I had to make some alterations to get them going because they use deprecated APIs. When I initially ran into this problem, I considered there was no additional work to get B-frames working. [20:22:34 CEST] <zerodefect> *no=now :) [21:06:53 CEST] <DHE> My video decoding application using avcodec_send_packet/receive_frame is losing a huge amount of data. On a test stream that's only 30 seconds long (29.97fps) I lose ~59 frames when decoding. [21:07:35 CEST] <DHE> Yes I send a null packet and collect as much output as possible from receive frame when the input ends. I get a couple extra frames out but not nearly enough for the whole video [21:36:11 CEST] <kepstin> DHE: where are the frames getting "lost"? all missing from the end? are there gaps in timestamps scattered throughout? [21:38:29 CEST] <DHE> kepstin: trying to determine that now... was hoping someone might have an idea off the top of their head of what I might have missed... [21:39:14 CEST] <kepstin> the first thing to check is whether the file actually has all the frames you think it does, e.g. compare the output of ffprobe -show_frames [21:39:27 CEST] <DHE> I'm outputting the video twice - once as a remux and once as a transcode - in the same process from the same AVFormatContext doing the reading. they're producing dramatically different lengths [21:46:57 CEST] <imperito> Any suggestions on how I might make a web compatible live-stream out of a low-rate data source? [21:47:43 CEST] <imperito> (I'm not very familiar with ffmpeg, the folks at #python recommended it) [21:48:08 CEST] <DHE> HLS or MPEG-DASH might be usable straight-up, depending on player capabilities. these have the advantages of being served by an HTTP server. otherwise you need something like an RTMP server [21:48:18 CEST] <kepstin> imperito: use ffmpeg to convert to the HLS (or DASH) segment muxer, re-encode to h264/aac if it's in some other codec. Serve files via HTTP server. [21:49:00 CEST] <ChocolateArmpits> kepstin, he's talking about livestreaming, I don't think ffmpeg supports dash livestreaming [21:49:24 CEST] <kepstin> hmm, it doesn't? pity. It's not something I've tried tho. [21:49:29 CEST] <kepstin> the HLS should work at least. [21:49:41 CEST] <imperito> Serve files... I guess I was assuming I'd emit some stream of whatever video format is in vogue and that would be my endpoint. Is that not how it is done? [21:49:59 CEST] <furq> not if you want to stream to a browser without flash [21:50:01 CEST] <ChocolateArmpits> kepstin, seems only webm dash [21:50:10 CEST] <kepstin> imperito: ffmpeg isn't a server, so it needs some other distribution server to send the media to clients [21:50:39 CEST] <kepstin> so e.g. HLS can be served by a web server, or another alternative is to send media via rtmp to the nginx-rtmp module, which can serve both HLS and rtmp streams to clients. [21:51:13 CEST] <furq> if your encoder needs to be separate from the endpoint then use nginx-rtmp [21:51:15 CEST] <DHE> in a local subnet you can multicast out a video stream. unicast streams are also possible but a receiver needs to be set up ahead of time. [21:51:19 CEST] <furq> otherwise just use ffmpeg's hls muxer directly [21:51:43 CEST] <furq> DHE: i don't know if that qualifies as "web-compatible" [21:51:55 CEST] <imperito> OK, yes, I would definitely want to be served to a normal web browser. Like you open example.com/video in chrome or on an iphone and a video plays [21:52:21 CEST] <DHE> yeah, HLS can make that work. I have some videos like that on live webcams. [21:52:37 CEST] <furq> imperito: https://github.com/video-dev/hls.js [21:52:42 CEST] <furq> you'll need that for desktop browsers [21:52:43 CEST] <imperito> Yeah, that's pretty much the idea I have, is something like a webcam [21:53:12 CEST] <DHE> yeah. I got a livestreaming webcam pointed at the construction site outside my office. running ffmpeg for the last ~2 weeks or so streaming [21:53:20 CEST] <imperito> except instead of a camera producing the input it is a function [21:53:56 CEST] <imperito> So would the input be like a directory that it could watch for frames, or a FIFO or something like that? [21:54:16 CEST] <ChocolateArmpits> imperito, what's your input ? [21:54:19 CEST] <DHE> fifo could work. a directory full of files works but not so well for live-updates [21:54:23 CEST] <furq> if you're generating input programmatically then you probably just want to pipe it into ffmpeg [21:54:47 CEST] <furq> python foo.py | ffmpeg -f rawvideo -i - ... [21:54:48 CEST] <kepstin> if your input is actually a webcam, ffmpeg can probably read it directly [21:54:54 CEST] <imperito> ChocolateArmpits: ultimately it is a radiometer on a satellite. but there is so much conversion I have to do that it might as well be programmatic [21:55:41 CEST] <kepstin> yeah, piping it to ffmpeg is probably the best option then. Make sure you're using an IO thread on the writer side, since the writes might block. [21:58:05 CEST] <imperito> So if I did something like python foo.py | ffmpeg [stuff] it would output these HLS files which if I put in an HTTP server it would have the effect of a live video? [21:58:20 CEST] <furq> it generates a bunch of segments and an m3u8 playlist [21:58:29 CEST] <imperito> Like, someone coming in later would get the current video, as opposed to starting from the beginning? [21:58:37 CEST] <furq> point a video tag at the m3u8 and it'll play them back [21:58:44 CEST] <furq> by default it'll start two or three segments from the latest [21:58:57 CEST] <imperito> Oh, I've seen m3u8 files before. On totally legitimate live sports streaming sites... [21:59:14 CEST] <furq> filthy [22:00:12 CEST] <imperito> I guess I'd need to delete old... segments? Or does it do that automatically as like a rolling store? [22:00:24 CEST] <furq> it does that automatically if you ask it to [22:00:30 CEST] <imperito> clever [22:00:34 CEST] <furq> !muxer hls [22:00:34 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-formats.html#hls-1 [22:03:10 CEST] <imperito> Thanks. piped input, HLS output, http server. Sounds reasonable [22:06:27 CEST] <imperito> What about frame rate? Is it going to be a problem if my input only updates every 1-2 seconds? [22:10:29 CEST] <TMM> hi all [22:11:31 CEST] <TMM> I'm working on completing some support for the interplay mve format (outside of ffmpeg at the moment) I'm using this information : https://wiki.multimedia.cx/index.php/Interplay_MVE I haven't quite figured out how opcode 0x6 works but I have more information [22:11:56 CEST] <TMM> does someone here happen to know if multimedia mike is on irc? I have some questions and additions to that page [23:07:08 CEST] <echelon> hi :) [23:07:54 CEST] <echelon> i have an mpeg-ts container with h.264/aac encoded video, and i want to convert it to a .m4v container [23:08:22 CEST] <echelon> will it need to be re-encoded? [23:08:55 CEST] <ChocolateArmpits> echelon, no [23:09:04 CEST] <echelon> cool [23:09:30 CEST] <ChocolateArmpits> use this : ffmpeg -i input.mp4 -vcodec copy -an output.m4v [23:09:44 CEST] <ChocolateArmpits> this will strip the audio and copy video frames only [23:09:44 CEST] <sfan5> umm [23:09:45 CEST] <echelon> why no -an? [23:09:48 CEST] <sfan5> that will omit audio [23:09:52 CEST] <sfan5> just use -c copy [23:10:00 CEST] <ChocolateArmpits> isn't m4v strictly for video ? [23:10:02 CEST] <furq> no [23:10:03 CEST] <echelon> why do i wanna strip audio again? lol [23:10:26 CEST] <ChocolateArmpits> ok then remove -an [23:10:27 CEST] <sfan5> pretty sure .m4v is just a fancy way of saying .mp4 [23:10:30 CEST] <sfan5> i might be wrong though [23:10:36 CEST] <furq> it is [23:10:36 CEST] <sfan5> ChocolateArmpits: then he would be re-encoding the audio [23:10:39 CEST] <furq> but then so is m4a [23:10:52 CEST] <ChocolateArmpits> so he should use -codec copy [23:10:56 CEST] <sfan5> indeed [23:11:16 CEST] <furq> m4v and m4a are mostly used by itunes [23:11:48 CEST] <echelon> another thing.. the .ts file lacks seekability, can't skip around easily as there's no timestamp when it plays [23:11:54 CEST] <furq> m4a will use -f ipod with ffmpeg, but m4v and mp4 are identical [23:12:04 CEST] <echelon> so will it be indexed and added to the m4v? [23:12:07 CEST] <furq> echelon: that's an inherent property of mpegts [23:12:15 CEST] <furq> mp4 will be seekable [23:12:20 CEST] <echelon> oh, cool [23:12:59 CEST] <echelon> furq: i copied the mpegts from an encrypted stream, so i don't know how it's able to let me seek on the web browser, but not in any local video player [23:13:20 CEST] <furq> there's no seek index [23:13:32 CEST] <furq> you can bruteforce seek, but some players just don't do that [23:25:33 CEST] <notbrontosaurusr> can you please unban me? [23:26:28 CEST] <notbrontosaurusr> freshly compiled ffmpeg on Debian with libxcb: How do I screencapture with mouse pointer? [23:26:53 CEST] <notbrontosaurusr> this: ffmpeg -hide_banner -f x11grab -r $fps -s 1920x1200 -i :0.0 \ [23:26:53 CEST] <notbrontosaurusr> -vcodec libx264 -preset medium -tune fastdecode -pix_fmt yuv420p -crf 30 -an -y [23:26:58 CEST] <notbrontosaurusr> is not working. [23:27:26 CEST] <notbrontosaurusr> I mean, it is working, only without the pointer. [23:29:01 CEST] <DHE> https://www.ffmpeg.org/ffmpeg-all.html#x11grab parameter "-draw_mouse 1" [23:29:06 CEST] <DHE> start with that [23:29:18 CEST] <notbrontosaurusr> DHE: thanks. [23:31:28 CEST] <notbrontosaurusr> ffmpeg -hide_banner -f x11grab -draw_mouse 1 .... ? [23:31:36 CEST] <DHE> looks right [23:31:50 CEST] <notbrontosaurusr> Did't do the trick, should i blame nvidia drivers? [23:36:22 CEST] <DHE> uhh, what? [23:36:32 CEST] <DHE> what's nvidia got to do with anything? [23:37:06 CEST] <notbrontosaurusr> dunno, guessing, the other intel machine is working as it should (older ffmpeg compile thought) [23:39:38 CEST] <notbrontosaurusr> ok, it is working with debian version; ffmpeg version 3.2.5-1 [23:40:10 CEST] <notbrontosaurusr> DHE, thanks, later. And if you ppl can unban me, that would be great ;) [23:52:50 CEST] <DHE> silly silly people asking nicely to be unbanned... [00:00:00 CEST] --- Sat Jun 3 2017

1 0

ffmpeg-devel.log.20170601
by burek 02 Jun '17

02 Jun '17

[01:01:27 CEST] <jkqxz> wm4: Can you see any problems with libva changing the SONAME and then disallowing loading old drivers? I think that fixes everything going forward (destroy buffers if libva2, don't if libva1 except quirk for intel), but I might be missing something. [01:01:50 CEST] <jkqxz> (Ignoring the broken intermediate releases.) [01:02:20 CEST] <wm4> jkqxz: that sounds fine [01:02:34 CEST] <wm4> is the bug in the individual drivers? [01:03:13 CEST] <jkqxz> Which bug? [01:04:02 CEST] <wm4> the buffer destruction semantics [01:04:10 CEST] <jkqxz> One consequence of that change would be that it would kill the vdpau wrapper unless someone takes it over and updates it to libva2. [01:04:32 CEST] <wm4> that would probably make the world a better place [01:04:41 CEST] <wm4> anyway I yelled a lot at intel's direction and now I feel better [03:04:57 CEST] <stevenliu> <ubitux> you mean rotate, yes; <ubitux> you have the rotate filter.. no, do you have it? [06:20:13 CEST] <cone-477> ffmpeg 03James Almer 07master:bd1179e36bad: avutil/pixfmt: remove superfluous define [07:50:13 CEST] <ubitux> stevenliu: -vf rotate is present in the codebase [07:51:01 CEST] <stevenliu> Thanks, let me try to use it :) [07:54:34 CEST] <stevenliu> Ahaha, That's cool [07:54:44 CEST] <stevenliu> very nice function :) [10:17:44 CEST] <AaronL> maybe I'm missing something here, but as far as I can tell, av_write_trailer() does nothing in practice for mpegts [10:18:33 CEST] <AaronL> in mpegtsenc.c, mpegts_write_end() is set to write_trailer(), and all this does is a flush [10:18:46 CEST] <AaronL> I looked at other enc avformats, and most do quite a bit [10:18:54 CEST] <AaronL> of work to write a trailer [10:18:59 CEST] <nevcairiel> mpegts doesnt have headers or footers, so neither write_header or write_trailer do anything really [10:19:07 CEST] <nevcairiel> its the fate of a streaming format [10:20:02 CEST] <nevcairiel> (or broadcast format) [10:20:17 CEST] <AaronL> well, there must be some sort of header to identify the programs and streams in it, right? [10:20:28 CEST] <nevcairiel> its not actually a header though [10:20:37 CEST] <nevcairiel> it gets repeated all over [10:20:59 CEST] <AaronL> well, I think the rate at which it is repeated is controllable [10:22:38 CEST] <alevinsn> ok, so, there is no real way to know that an mpeg TS is finished being sent from the TS itself? [10:23:28 CEST] <alevinsn> other than it stops getting packets, I guess, although that could be caused by a number of different things [10:24:03 CEST] <wm4> well broadcast streams rarely actually stop [10:25:01 CEST] <alevinsn> ok [10:25:50 CEST] <alevinsn> totally unrelated, when I use h264_qsv for decoding 1080i59.94 video, I noticed that it is reporting the duration incorrectly for each video frame [10:26:01 CEST] <alevinsn> I looked into the cause [10:26:09 CEST] <alevinsn> and its complicated [10:26:17 CEST] <nevcairiel> duration information is often quite inaccurate [10:26:38 CEST] <alevinsn> well, in this case, its wrong for a pretty understandable reason [10:26:53 CEST] <alevinsn> but, I'm not sure of the right way to fix it [10:27:05 CEST] <BtbN> I don't think the decoder is involved with the duration at all [10:27:09 CEST] <alevinsn> with 1080i59.94, the frame rate is 30000/1001 [10:27:10 CEST] <BtbN> it just re-orders timestamps [10:27:12 CEST] <alevinsn> it is [10:27:16 CEST] <alevinsn> but I'll get to that [10:27:37 CEST] <alevinsn> but, in an mpegts, the timebase is 90000/1 [10:27:50 CEST] <alevinsn> so, the first video frame pts is 3003 [10:27:58 CEST] <alevinsn> and it ought to have a duration of 3003 as well [10:28:15 CEST] <alevinsn> but, instead, it gets a duration of 1501 [10:28:45 CEST] <nevcairiel> sounds like something wm4 might get upset about =p [10:28:46 CEST] <alevinsn> The duration is calculated by ff_compure_frame_duration() for each packet [10:29:07 CEST] <alevinsn> and, it does this by using st->internal->avctx->ticks_per_frame [10:29:22 CEST] <alevinsn> which happens to be 2 in this case--there is a comment associated with ticks_per_frame [10:29:31 CEST] <alevinsn> indicating that it is 2 for H.264 and MPEG-2 [10:29:37 CEST] <alevinsn> although, I wonder if that comment is correct [10:29:48 CEST] <alevinsn> however h264_qsv doesn't set ticks_per_frame [10:30:17 CEST] <alevinsn> st->internal->avctx is actually an AVCodecContext * for the default H.264 decoder [10:30:29 CEST] <alevinsn> I tried passing in a whitelist [10:30:42 CEST] <alevinsn> but that doesn't work at all, because when probing, there is a sort of kludge in the code [10:30:54 CEST] <alevinsn> that forces it to load the default H.264 decoder no matter what if the codec ID is H.264 [10:31:29 CEST] <nevcairiel> the packet timestamps should be entirely independent of whatever decoder is used later [10:31:38 CEST] <alevinsn> the packet timestamps are correct [10:31:47 CEST] <alevinsn> it is the calculated durations that are wrong, divided by 2 [10:32:05 CEST] <nevcairiel> ff_compute_frame_duration is used during demuxing, either its always wrong or always right, it must not depend on the decoder used [10:32:57 CEST] <BtbN> some decoders might strip the duration though. I'm not sure how I did in in cuvid [10:32:59 CEST] <alevinsn> I think it always ends up being wrong in the case that the H.264 decoder that is actually used is not the default H.264 decoder (i.e. the software one) [10:33:15 CEST] <alevinsn> if it uses the software decoder, I think it will be correct [10:33:16 CEST] <nevcairiel> or the decoder is handling it wrong =p [10:33:30 CEST] <alevinsn> there are two issues I think [10:33:44 CEST] <alevinsn> first, I'm not sure if setting ticks_per_frame to 2 is legit in any situation [10:34:03 CEST] <alevinsn> the comment in avcodec.h indicates that this is the right thing to do for H.264 and MPEG-2 [10:34:21 CEST] <alevinsn> that these codecs use a "time base that is closer to the field rate than the frame rate" [10:35:14 CEST] <alevinsn> second, the fact that there is this internal codec context for each stream is also cause for concern [10:35:29 CEST] <alevinsn> particularly since it may not necessarily be equivalent to the one that the user picks [10:35:43 CEST] <nevcairiel> its an internal implementation detail, its totally irrelevant to the user [10:36:00 CEST] <alevinsn> well, in this case, it is relevant, because it results in the duration being calculated incorrectly [10:36:15 CEST] <nevcairiel> or it doesn't and qsv just screws up [10:36:19 CEST] <nevcairiel> which in my mind is far more likely [10:36:32 CEST] <alevinsn> no, the duration isn't populated at all by QSV [10:36:35 CEST] <alevinsn> I confirmed it [10:36:43 CEST] <nevcairiel> maybe thats the problem =p [10:36:44 CEST] <alevinsn> it is entirely calculated [10:36:45 CEST] <nevcairiel> interlaced is messy [10:37:03 CEST] <alevinsn> I think it will be wrong regardless of interlaced or progressive actually [10:37:07 CEST] <nevcairiel> mixing field and frame durations can get annoying [10:37:13 CEST] <alevinsn> will always be divided by 2 [10:37:31 CEST] <alevinsn> because it uses ticks_per_frame from the internal context for that calculation [10:37:41 CEST] <alevinsn> and h264_qsv doesn't set ticks_per_frame [10:37:49 CEST] <nevcairiel> so maybe qsv should just behave and set ticks_per_frame like every good h264 decoder? :) [10:37:50 CEST] <alevinsn> and neither do the rest of the H.264 decoders for that matter [10:38:30 CEST] <alevinsn> I mean, the hardware H.264 decoders [10:39:04 CEST] <alevinsn> it looks like libx264 doesn't even set it [10:39:30 CEST] <nevcairiel> its an encoder [10:39:33 CEST] <nevcairiel> its different [10:39:48 CEST] <alevinsn> ok, right, I figured it might be used for decoding as well [10:40:09 CEST] <wm4> soon enough it should become unneeded to use the qsv decoder [10:40:15 CEST] <wm4> and you can just use dxva or vaapi [10:40:28 CEST] <alevinsn> true, but it looks like this will be an issue for h.264 dxva or vaapi decoders as well [10:40:34 CEST] <nevcairiel> no it wont [10:40:36 CEST] <alevinsn> neither of which sets the duration [10:41:01 CEST] <alevinsn> which makes me think that the duration for those decoders is calculated the same way [10:41:27 CEST] <nevcairiel> just set ticks_per_frame in the hardware decoders if they dont handle durations themself somewhere [10:41:59 CEST] <alevinsn> that might not be enough in and of itself [10:43:18 CEST] <alevinsn> the code in h264dec.c also adjusts time_base.den [10:43:35 CEST] <wm4> time_base is outdated [10:44:08 CEST] <alevinsn> time_base in general or just the one for AVCodecContext ? [10:44:36 CEST] <wm4> time_base for decoding [10:44:44 CEST] <wm4> in AVCodecContext [10:44:59 CEST] <alevinsn> the one in AVStream is still relevant I would think [10:45:01 CEST] <wm4> it's supposed to be used for encoding only [10:45:05 CEST] <wm4> yes [10:45:46 CEST] <alevinsn> but, is using 2 for ticks_for_frame correct for H.264 in the first place? [10:46:00 CEST] <alevinsn> someone obviously thought so [10:46:24 CEST] <alevinsn> and H.264 always uses 2 for ticks_per_frame [10:46:29 CEST] <alevinsn> for both progressive and interlaced [10:47:18 CEST] <wm4> I think this is just for making "space" in the timebase so you can sneak in fields [10:47:30 CEST] <wm4> progressive and interlaced can switch midstream anyway [10:47:50 CEST] <alevinsn> then, would it be relevant for HEVC as well? It isn't being done there [10:48:20 CEST] <alevinsn> At least with QSV encoding, it only deals with interleaved frames [10:48:28 CEST] <alevinsn> and doesn't encode fields separately [10:49:15 CEST] <nevcairiel> hevc has practically no interlacing support, and our decoder doesnt support it at all [10:49:38 CEST] <nevcairiel> it only has some metadata to interleave individual fields coded as frames, but they are not very special [11:37:48 CEST] <BtbN> Can I just use the _WIN32 macro in ffmpeg C code, or is there some configure macro I should check instead? [11:38:24 CEST] <nevcairiel> BtbN: it depends what exactly for [11:38:46 CEST] <BtbN> The driver version nvenc needs differs between Windows and Linux, and I want to display the correct one in an error message. [11:39:05 CEST] <nevcairiel> its probably fine using _WIN32 then [11:39:36 CEST] <nevcairiel> did you consider making use of the probe function conditional if its present or something? it seems to dump up the requirement quite a bunch without real tangible improvement [11:39:58 CEST] <BtbN> There is no capabilty to check if the driver version is sufficient for the used SDK header [11:40:24 CEST] <BtbN> I'm not actually sure at which point it explodes if you use a too old driver, but I'm about to find out [11:42:13 CEST] <BtbN> Or what do you mean by probe function conditional? [11:42:23 CEST] <nevcairiel> the getcaps function [11:42:30 CEST] <nevcairiel> it seems to be what mostly requires the very new driver [11:43:21 CEST] <BtbN> oh, you mean NvEncodeAPIGetMaxSupportedVersion [11:43:34 CEST] <BtbN> that was already there in SDK 7, I'm pretty sure [11:44:13 CEST] <nevcairiel> i actually meant cuvidGetDecoderCaps in the decoder [11:44:36 CEST] <BtbN> oh, that [11:44:40 CEST] <BtbN> It's already using that [11:44:49 CEST] <nevcairiel> i'm saying maybe it shouldnt [11:45:02 CEST] <nevcairiel> or only if its actually present [11:45:12 CEST] <nevcairiel> because that one call bumps up the driver versions way high [11:45:26 CEST] <BtbN> Just using the newer header bumps the driver version [11:45:34 CEST] <nevcairiel> not really [11:46:22 CEST] <nevcairiel> older drivers seemed to just fail if you request P016 output, as far as i can tell, for example [11:48:59 CEST] <BtbN> I'm pretty sure just loading all the functions will fail on an older driver [11:49:09 CEST] <BtbN> it won't ever get to actually calling anything [11:49:37 CEST] <nevcairiel> thats not the drivers fault, thats your codes doing - the only "new" function is the one i mentiooned above [12:46:57 CEST] <BtbN> nevcairiel, https://github.com/BtbN/FFmpeg/commit/ff3084606c09911cdd3b6d6b588c47b9e71ac… https://github.com/BtbN/FFmpeg/commit/f890a6d71286cd4602a778fc551df0b4d87bc… seems to actually work on an old driver [12:47:00 CEST] <BtbN> but might explode randomly [13:02:37 CEST] <nevcairiel> if you wanted to be really safe you could just disable 10-bit entirely, since its technically part of the same SDK release [13:22:31 CEST] <kiroma> Hey, where can I put a small feature request? [13:25:34 CEST] <atomnuker> here [13:26:49 CEST] <durandal_1707> kiroma: about what? [13:28:01 CEST] <kiroma> Simply don't display error message about overwriting file if the output filename is "/dev/null" or "-pass 1" is specified. [13:28:42 CEST] <kiroma> *and [13:46:12 CEST] <wm4> does anyone know why h264_mp4toannexb_bsf specifically waits for IDRs before adding sps/pps? [13:46:28 CEST] <wm4> couldn't it just dump all sps/pps at the beginning of the stream [13:46:39 CEST] <nevcairiel> that would technically be invalid [13:46:45 CEST] <nevcairiel> it should be before the IDR [13:47:29 CEST] <wm4> no idea if I'm reading this right, but it seems to append _after_ the IDR (which confuses me additionally) [13:47:48 CEST] <Compn> kiroma : sure, i can make a trac ticket for that if you dont want to [13:48:50 CEST] <wm4> nevcairiel: or does your statement refer to my suggestion to dump sps/pps at the start of the stream [13:48:54 CEST] <BBB> ubitux: ping [13:49:14 CEST] <nevcairiel> wm4: that, but it should be before the IDR, otherwise it seems rather pointless [13:49:53 CEST] <wm4> if you dump them at the start (before any other NALs), shouldn't the decoder parse and store them [13:50:25 CEST] <nevcairiel> in practice perhaps, but the stream would still be possibly invalid [13:50:46 CEST] <nevcairiel> that thing is not only used for our decoders but also for remuxing, in which case you want to make fully valid streams [13:51:13 CEST] <wm4> so what's invalid about it? that they are not repeated? [13:51:26 CEST] <nevcairiel> there is specs that say where it should go [13:51:32 CEST] <nevcairiel> cant just randomly throw it everywhere [13:51:33 CEST] <ubitux> BBB: pong [13:51:47 CEST] <wm4> yeah, I'm trying to look [13:52:17 CEST] <nevcairiel> the code talks about predening [13:52:55 CEST] <nevcairiel> and it also seems to do that [13:53:06 CEST] <wm4> oh I see now [13:53:15 CEST] <nevcairiel> prepending* [13:53:15 CEST] <wm4> blergh [13:53:19 CEST] <nevcairiel> shouldnt just skip syllables [13:53:57 CEST] <wm4> (reading libav's code helps lol) [14:02:28 CEST] <kiroma> Compn: Sure, thanks. [14:09:31 CEST] <Compn> kiroma : what ver ffmpeg are you using ? [14:15:58 CEST] <kiroma> I'm building new versions every week or so using git pull [14:16:39 CEST] <Compn> k [14:17:03 CEST] <Compn> kiroma : http://trac.ffmpeg.org/ticket/6435#ticket [14:21:11 CEST] <kiroma> I think it should still check if the filename already exists if "-pass 1" is specified, because then you could accidentally overwrite an existing video with an empty file. [14:23:37 CEST] Action: Compn updates [14:23:38 CEST] Action: Compn afk [14:23:56 CEST] <Compn> and there goes my english capabilities [14:24:04 CEST] <Compn> is devnull is specified :\ [14:52:33 CEST] <RiCON> has it ever been suggested to use @file/response file at least for the library linking commands? [14:53:41 CEST] <DHE> are command-line lengths an issue? [14:53:58 CEST] <RiCON> using a certain number of external libs and long enough paths is going over the 32767 limit on Windows [14:55:53 CEST] <RiCON> example: http://sprunge.us/hiLh [14:57:23 CEST] <RiCON> i workaround it by deduplicating -L and -l options, but the lib*/*.o options on their own take 22888 characters [14:57:28 CEST] <nevcairiel> perhaps thats because it repeats the same library path 100 times? :D [14:59:07 CEST] <RiCON> i'd suggest a fix for it, but makefile syntax looks like chinese [15:00:14 CEST] <wm4> chinese is probably fairly simple compared to make [15:01:24 CEST] <atomnuker> ^^the truth, m4 is alien level [15:01:37 CEST] <nevcairiel> nothing in ffmpeg is m4 [15:01:43 CEST] <DHE> lib*/*? not using the libav*.a instead? [15:01:58 CEST] <RiCON> that's for the shared libs [15:02:17 CEST] <RiCON> the sprunge link, that is [15:02:53 CEST] <RiCON> the static lib command is apparently shorter [15:03:11 CEST] <nevcairiel> well it lacks all sorts of linking commands, only has object files [15:16:28 CEST] <LA> hey. guys, please help me. why logging doesn't work on 64 bit ffmpeg? I set callback by av_log_set_callback, and it's ok on 32 bit, but with 64 bit I don't receive anything. [15:44:44 CEST] <BtbN> Is the github mirror updated with a hook by now, or is it some cron job? [16:09:42 CEST] <cone-477> ffmpeg 03Srinath K R 07master:d8da329cc364: avcodec/nvenc: Add default value for AVCodecContext::refs [16:09:43 CEST] <cone-477> ffmpeg 03Timo Rothenpieler 07master:2d978d1c721a: configure: libnpp does not need to link libcuda [16:09:44 CEST] <cone-477> ffmpeg 03Timo Rothenpieler 07master:cb3358b68fa7: avcodec/nvenc: print minimum driver version on error [16:09:45 CEST] <cone-477> ffmpeg 03Timo Rothenpieler 07master:f890a6d71286: compat/cuda: make cuvidGetDecoderCaps optional [16:09:46 CEST] <cone-477> ffmpeg 03Timo Rothenpieler 07master:ff3084606c09: avcodec/cuvid: make capability check optional [16:13:43 CEST] <ubitux> is it legit to use checkasm to only bench the functions and not actually test them? [16:15:07 CEST] <nevcairiel> if you can already call th em with some valid data, comparing that to the output of the C version seems trivial? :) [16:18:41 CEST] <ubitux> depends if it's fuzzy floats :p [16:19:44 CEST] <ubitux> oh we have a float_near_ulp_array thing [16:22:40 CEST] <jamrial> ubitux: there's float_near_abs_eps as well. look at synth_filter.c for float tests [16:23:12 CEST] <jamrial> also dcadsp.c, although that one is disabled in our tree [16:26:07 CEST] <ubitux> oh "ulp" is some soft float thing? [16:26:10 CEST] <ubitux> what does it stand for? [16:36:45 CEST] <ubitux> ulp = "unit in the last place"? [16:36:46 CEST] <jkqxz> <https://en.wikipedia.org/wiki/Unit_in_the_last_place>. For this, it should be how many floating point numbers are between your two values. [16:37:25 CEST] <jkqxz> The implementation there looks pretty dubious, though - it's going to say that 1.0 and 0.999999999... are very far apart. [16:37:40 CEST] <ubitux> i wonder which i should use, arbitrary epsilon or ulp [16:38:06 CEST] <ubitux> i guess i'll go for an epsilon with 0.0001 [16:38:17 CEST] <ubitux> float_near_abs_eps_array() seems not used [16:38:31 CEST] <ubitux> float_near_ulp_array() has a few usages [16:41:06 CEST] <jamrial> float_near_abs_eps_array() is not used because synth_filter wanted to print errors inside the loop, so it reimplemented it using float_near_abs_eps() directly [16:41:56 CEST] <jamrial> no, my bad, that was dcadsp.c [16:44:23 CEST] <nevcairiel> jkqxz: how so, it uses the bitpattern in an int to compare, and 1.0 and 0.999999999 look very similar in that [16:45:43 CEST] <nevcairiel> ie. 1.0 is 0x3f800000 and 0.9999999 is 0x3f7ffffe [16:47:20 CEST] <nevcairiel> which is just a difference of 2 ulps [16:47:21 CEST] <jkqxz> Hmm, right. I was thinking that the mantissa was going to mess with it, but it doesn't for sensible numbers. Only sign and infinities get you. [16:47:50 CEST] <jkqxz> *exponent [16:47:59 CEST] <nevcairiel> 0.0000001 and -0.0000001 would probably screw this over [16:48:20 CEST] <nevcairiel> but inaccuary should generally not flip the sign [16:48:34 CEST] <jkqxz> Subnormals already screw with that, there are a lot more numbers close to zero. [16:50:12 CEST] <nevcairiel> anything close to zero will likely fail because the exponent also changes then [16:50:18 CEST] <nevcairiel> or could change [16:50:31 CEST] <nevcairiel> even without going into subnormal range [16:51:39 CEST] <nevcairiel> could even encounter that at 0.1 vs 0.099 [18:09:27 CEST] <jamrial> oh, fuck this, it was fixed_dsp the test that was fucking with float_dsp [18:09:45 CEST] <jamrial> because i was giving the same names to both in check_func() [18:16:58 CEST] <cone-477> ffmpeg 03James Almer 07master:93dc1c122185: checkasm: add _fixed suffix to fixed_dsp tests [18:38:04 CEST] <wm4> ffmpeg.c truly is a rotten piece of shit [18:38:21 CEST] <wm4> it doesn't do packet refcounting correctly, instead it does absurd brainfucked shit [18:38:27 CEST] <wm4> which cost me a few hours of shit [18:48:13 CEST] <wm4> this shit is so bad [19:01:52 CEST] <kierank> wm4: amen [19:02:29 CEST] <wm4> and libav's API also goes on my nerves [19:02:49 CEST] <wm4> why in heaven's fuck do you need to provide a "cleared" packet for the first ref in av_buffer_ref [19:03:01 CEST] <wm4> why doesn't it either unref or completley erase that packet [19:03:11 CEST] <wm4> s/erase/overwrite/ [19:46:51 CEST] <jamrial> Gramner: checkasm can't currently handle dsp functions that return a float value (instead of void or an int) [19:46:59 CEST] <jamrial> it fails on x86_32 apparently because emms is always issued in call_ref/new() [19:52:58 CEST] <Gramner> jamrial: did you use declare_func_emms? [19:53:15 CEST] <jamrial> Gramner: yes, that still calls emms [19:54:26 CEST] <Gramner> oh, it does [19:54:47 CEST] <jamrial> Gramner: https://github.com/jamrial/FFmpeg/tree/floatdsp [19:55:02 CEST] <jamrial> works on x86_64, fails on x86_32 [19:59:29 CEST] <Gramner> probably drop the emms instruction in checked_call I guess. although that may possibly break something else [19:59:53 CEST] <Gramner> this is one of the reasons why I don't like mmx [20:00:50 CEST] <jamrial> how about adding a new checked_call() func without the emms? [20:02:25 CEST] <Gramner> jannau wrote the emms stuff in checkasm, maybe check with him if he thought about it. also I think the _emms suffix usage is kind of backwards [20:02:40 CEST] <jamrial> removing the emms in checked_call() makes fifteen tests fail, so not an option :p [20:04:59 CEST] <Gramner> adding another checked_call implementation for functions returning a float is a possibility. dunno if there's a cleaner way [20:06:21 CEST] <Gramner> the 32-bit x86 calling convention for returning floating point values is stupid as fuck for requiring x87 in the first place but we just have to live with that [20:36:07 CEST] <jamrial> Gramner: something like https://pastebin.com/Y1UUC0n7 ? [21:11:28 CEST] <cone-477> ffmpeg 03Vittorio Giovara 07master:88521a753761: ffprobe: Print AVMasteringDisplayMetadata side data contents [21:11:29 CEST] <cone-477> ffmpeg 03Vittorio Giovara 07master:2934a10f2ed3: ffprobe: Print AVContentLightMetadata side data contents [21:26:44 CEST] <cone-477> ffmpeg 03Paul B Mahol 07master:dc72d1dde914: avfilter: add audio surround upmixer [22:55:31 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07master:cd6f319a7470: avcodec/cfhd: Fix runtime error: signed integer overflow: 65280 * 65288 cannot be represented in type 'int' [22:55:32 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07master:8b3e580b7f43: avcodec/wavpack: Fix runtime error: shift exponent 32 is too large for 32-bit type 'int' [22:55:33 CEST] <cone-477> ffmpeg 03Michael Niedermayer 07master:adb4854aac17: avcodec/asvdec: Use rounded up dimenensions in input size check [23:37:11 CEST] <Gramner> jamrial: yeah, I guess that would work [23:37:48 CEST] <Gramner> only need it on 32-bit though since 64-bit returns it in xmm0 [23:38:34 CEST] <cone-477> ffmpeg 03Kevin Mark 07master:3385989b98be: libavfilter/scale2ref: Add constants for the primary input [23:39:22 CEST] <kevmark> \o/ [23:43:31 CEST] <kevmark> Thanks for the merge Michael (if you're in here) [23:43:52 CEST] <michaelni> np [23:44:51 CEST] <kevmark> I believe this can be closed now https://trac.ffmpeg.org/ticket/5392 [23:57:19 CEST] <atomnuker> returning floats in xmm regs is probably one of the best ideas someone had [23:57:48 CEST] <atomnuker> most of the time all you want to do is SPLAT them so they're ready for that [23:58:21 CEST] <nevcairiel> amd64 uses xmm for all float operations, its not like the return register is a special case there [23:58:27 CEST] <BBB> its one of those duh moments where once youve cosnidered it, you cant imagine ever having done anything else [23:59:25 CEST] <BBB> kevmark: cehoyos will probably close it [23:59:54 CEST] <nevcairiel> x87 is idling quietly on amd64 most of the time, you can probably still use it if you really wanted to? [00:00:00 CEST] --- Fri Jun 2 2017

1 0

ffmpeg.log.20170601
by burek 02 Jun '17

02 Jun '17

[00:08:21 CEST] <ac_slater_> guys, is it possible to log certain parts of a pipeline with different levels? [01:02:14 CEST] <HoDANG> Hello. Does anyone have a compiled ffmpeg build for Win32 or Win64 with libfdk_aac that they could share, please? I'm only need the .exe file. I would really appreciate the help. Thanks. [01:05:53 CEST] <hotbobby> i have a question . im trying to figure out if there is a way i can take a mpeg2 stream and transcode it in real time [01:06:16 CEST] <hotbobby> like ffmpeg would output a x264 or something on the other end, how do you deal with streams? [01:07:08 CEST] <beandog> x264 can do that [01:07:11 CEST] <beandog> realtime encoding [01:07:21 CEST] <beandog> well, ffmpeg can obviously. -_- [01:08:43 CEST] <furq> how much did you pay for that domain [01:08:55 CEST] <hotbobby> furq: 40/yr for icann fees [01:09:06 CEST] <furq> what a bargain [01:09:11 CEST] <hotbobby> piss.io was taken :( [01:09:18 CEST] <furq> i know the guy who owns piss.io [01:09:28 CEST] <hotbobby> i, too, know jon hendren [01:09:43 CEST] <furq> are you a devops thought leader too [01:10:01 CEST] <hotbobby> no and really he isnt either. just a bad comedy writer [01:10:44 CEST] <furq> you're just jealous of his domain acquisition skill [01:11:37 CEST] <hotbobby> so im looking at stream input examples for ffmpeg. it would only end up giving me one flv or mkv or whatever as an output [01:11:57 CEST] <hotbobby> ideally i would like to have it such that any number of clients can watch the encoded stream. does that mean a new transcode for every client? [01:12:07 CEST] <furq> you can't use ffmpeg as a streaming server [01:12:27 CEST] <furq> you'd need to feed the output to something which actually does that, like nginx-rtmp [01:12:30 CEST] <hotbobby> okay, i need something else in addition then. but ffmpeg will work well for dealing with the gross mpeg2 [01:12:38 CEST] <hotbobby> yes thank you for your advice :) [01:12:46 CEST] <furq> or use ffmpeg's hls muxer and just serve those directly [01:12:54 CEST] <furq> assuming hls is good enough for what you're doing [01:14:52 CEST] <furq> https://github.com/arut/nginx-rtmp-module/wiki/Directives#exec_pull [01:14:54 CEST] <furq> i guess that's what you want [01:16:35 CEST] <hotbobby> yup! and i can link the resulting flv to jwplayer or whatever [01:16:50 CEST] <hotbobby> neat. i thought this would be a very difficult task [01:24:36 CEST] <furq> if you don't want to use flash then nginx-rtmp will remux to hls for you [01:24:51 CEST] <furq> which works in desktop browsers with https://github.com/video-dev/hls.js [01:25:05 CEST] <furq> assuming you don't mind 20 seconds of latency [01:36:31 CEST] <hotbobby> i would just encode it in such a way its ready for youtube but i dont think they like when you stream video games you didnt create yourself [01:38:38 CEST] <hotbobby> this is exciting ffmpeg has so many options. i was worried i wouldnt be able to keep the 5.1 ac3 but it wont even touch the audio unless i tell it to 8-) [01:51:48 CEST] <blue_misfit> hey gusy! [01:52:06 CEST] <blue_misfit> I've got a pathological DNxHD source that has some corruption or something equally nasty and when I transcode it I get a bunch of black video [01:52:41 CEST] <blue_misfit> the source plays normally in VLC but jumps from 12 - 19 seconds, so VLC also sees the glitch [01:52:49 CEST] <blue_misfit> how can I make ffmpeg abort with an error when it sees this? [01:55:08 CEST] <blue_misfit> -err_detect explode didn't have any effect :( [04:21:23 CEST] <ac_slater> hey guys, is there any downside to always calling av_interleaved_write_frame instead of av_write_frame? [06:20:19 CEST] <ac_slater> also, if AVStream->coded access is deprecated, what do we use instead? The examples havent been updated [06:21:11 CEST] <ac_slater> AVStream->codec * [06:23:35 CEST] <ac_slater> are we supposed to use AVStream->codecpar now? [06:31:35 CEST] <Bruutal> anybody know a good stock to invest on [06:32:23 CEST] <ac_slater> Bruutal: get out of here with that [06:32:33 CEST] <ac_slater> Bruutal: seriously leave us alone :( [06:32:33 CEST] <Bruutal> huh [06:32:50 CEST] <ac_slater> how many times did you ask #ffmpeg about that today? [06:33:19 CEST] <Bruutal> why you so upset [06:33:33 CEST] <ac_slater> you're wasting everyone's time man [06:33:48 CEST] <ac_slater> unless you're just trolling or whatever, fine but how many times in one day? [06:33:49 CEST] <Bruutal> not really [06:34:09 CEST] <Bruutal> i am not, i am being serious [06:34:17 CEST] <ac_slater> I was just in some channels that got hit pretty hard with spam so I'm angry at everyone [06:34:22 CEST] <Bruutal> if no new people join this room, then i will stop [06:34:25 CEST] <furq> i hear cocaine is a very good investment [06:34:36 CEST] <ac_slater> Bruutal: ask some investment rooms, I know there are some [06:34:43 CEST] <ac_slater> or somewhere else seriously [06:34:45 CEST] <Bruutal> ac_slater which ones? [06:34:56 CEST] <Bruutal> furq i don't do cocaine [06:35:02 CEST] <ac_slater> Bruutal: i dont fucking know, use your smart investor brain and find some [06:38:23 CEST] <ac_slater> furq: do you use libav* apis or do you stick to the command line tool? [06:38:42 CEST] <furq> i've hardly touched the apis and i've not touched the new 3.x apis [06:39:02 CEST] <ac_slater> furq: is there a nice changelog from 2.x to 3.x [06:39:04 CEST] <ac_slater> ? [06:39:33 CEST] <furq> i'm not aware of one for the libs [06:39:41 CEST] <furq> the ffmpeg one just lists new features [06:39:51 CEST] <ac_slater> yea all good [06:40:01 CEST] <ac_slater> the deprecation warnings are ok for now [06:40:35 CEST] <furq> the examples will be updated before deprecated apis are removed [06:40:49 CEST] <furq> if that's of any consolation to you [06:40:59 CEST] <ac_slater> ;) I'd hope so [06:41:23 CEST] <furq> i'm going to stop pluralising "api" now [06:44:52 CEST] <ac_slater> I never know which is correct [06:56:34 CEST] <dystopia_> [srt @ 04dd01e0] Unsupported subtitles codec: dvb_teletext [06:56:34 CEST] <dystopia_> Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument [06:56:38 CEST] <dystopia_> :( [06:56:50 CEST] <dystopia_> anyone know of a cli app that will extract dvb subs? [06:59:40 CEST] <furq> dystopia_: ffmpeg will do it with --enable-libzvbi [07:00:47 CEST] <dystopia_> thanks furq [07:01:49 CEST] <furq> assuming you actually mean dvb_teletext and not dvb_subtitle [07:08:00 CEST] <Speed_> hi i am havving troubble installing FFmpeg [07:08:01 CEST] <Speed_> https://hastebin.com/hipuhinize.lua [07:08:34 CEST] <Speed_> so i came here [07:08:41 CEST] <Speed_> how can i tell if its the latest version? [07:09:25 CEST] <Speed_> when i try to install libx256 it says i have the latest version alreaddy 1.9.3 [07:09:34 CEST] <Speed_> 1.9-3* [07:10:25 CEST] <Speed_> https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [07:10:32 CEST] <Speed_> i am following these instructions [07:12:50 CEST] <dystopia_> i have both formats furk [07:13:01 CEST] <dystopia_> furq* depends on the broadcaster [07:14:43 CEST] <ac_slater> Speed_: did you install the development package for libx265? [07:14:50 CEST] <ac_slater> cause it looks like you didnt [07:15:44 CEST] <Speed_> https://hastebin.com/unawereneh.sql [07:16:09 CEST] <Speed_> i think so [07:16:35 CEST] <ac_slater> do 'pkg-config --list-all | grep 265' [07:16:58 CEST] <Speed_> x265 x265 - H.265/HEVC video encoder [07:17:10 CEST] <ac_slater> hmm that's fucky [07:17:21 CEST] <Speed_> thats what? [07:17:28 CEST] <ac_slater> fucky [07:17:31 CEST] <ac_slater> something's weird [07:17:39 CEST] <furq> Speed_: check config.log [07:17:54 CEST] <ac_slater> maybe grep config.log for pkg-config calls to x265 to see what it's actually trying [07:18:36 CEST] <Speed_> where is this? [07:18:47 CEST] <ac_slater> where you ran ./configure from [07:19:31 CEST] <furq> just check the last 50 lines of ffbuild/config.log [07:20:03 CEST] <furq> normally "not found using pkg-config" actually means some compiler check failed [07:21:18 CEST] <Speed_> i cant see the config file [07:21:42 CEST] <Speed_> i assume you mean PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure \ [07:21:44 CEST] <Speed_> there [07:21:56 CEST] <Speed_> $HOME/ffmpeg_build/lib/pkgconfig [07:22:07 CEST] <Speed_> but i dont see the lib directory [07:22:28 CEST] <ac_slater> Speed_: he's talking about config.log . Should be right next to 'configure' [07:22:39 CEST] <furq> they moved it to ffbuild/ now [07:22:40 CEST] <furq> for some reason [07:22:42 CEST] <ac_slater> ooooh [07:22:46 CEST] <ac_slater> damn sorry [07:23:15 CEST] <Speed_> all i see in ffbuild is share [07:25:46 CEST] <furq> did you already run make clean or something [07:26:17 CEST] <Speed_> no [07:27:02 CEST] <furq> is there a config.log anywhere in the build directory [07:27:30 CEST] <Speed_> nope [07:27:37 CEST] <furq> fun [07:27:42 CEST] <furq> i guess rerun configure and see if it appears [07:28:39 CEST] <Speed_> only speed@Asimov:~/ffmpeg_build/share/man/man1$ ls nasm.1 ndisasm.1 exist [07:29:06 CEST] <Speed_> didnt apear after running the config [07:29:08 CEST] <furq> is this the source directory [07:29:58 CEST] <Speed_> i ran the config from the ffmpeg_sources [07:30:10 CEST] <furq> yeah it should be in there [07:30:12 CEST] <furq> not ffmpeg_build [07:31:01 CEST] <Speed_> theres a configure file in it [07:31:06 CEST] <Speed_> with no file extention [07:31:14 CEST] <furq> is there an ffbuild directory [07:31:24 CEST] <Speed_> yes [07:31:37 CEST] <Speed_> the log is there [07:32:04 CEST] <Speed_> what im i looking for here? [07:32:15 CEST] <furq> check the last 50 or so lines [07:32:31 CEST] <furq> pastebin them if there's nothing obvious in there [07:32:47 CEST] <Speed_> last line [07:32:47 CEST] <Speed_> ERROR: x265 not found using pkg-config [07:33:45 CEST] <Speed_> https://hastebin.com/ozukoxemoj.cpp [07:34:15 CEST] <furq> /usr/bin/ld: cannot find -lnuma [07:34:17 CEST] <furq> there's your problem [07:34:21 CEST] <furq> install libnuma [07:35:16 CEST] <ac_slater> maybe a bug should be filed to check for that? [07:35:57 CEST] <Speed_> how do i get that? [07:36:05 CEST] <Speed_> apt-get didnt find it [07:36:18 CEST] <ac_slater> ugh [07:36:24 CEST] <furq> libnuma-dev [07:36:43 CEST] <furq> you might need to rebuild libx265 as well [07:36:54 CEST] <furq> i imagine multithreading is broken if you built it without libnuma installed [07:36:59 CEST] <ac_slater> yea [07:37:33 CEST] <furq> it's probably better that ffmpeg always checks for that, since there's no good reason to build x265 without it [07:37:41 CEST] <ac_slater> I always wondered why certain apps NEED libnuma... I guess they want to pin threads to cores or require a certain amount of physical cores [07:39:12 CEST] <furq> actually i wonder if that's an x265 bug [07:39:17 CEST] <furq> i assume -lnuma is coming from pkg-config [07:39:35 CEST] <furq> but x265 sucks anyway so who cares [07:40:35 CEST] <ac_slater> it's not [07:40:52 CEST] <ac_slater> sadly apparently x265's pkgconfig file doesnt contain libnuma [07:46:43 CEST] <Speed_> this is taking forever xD [07:47:18 CEST] <thebombzen> "Speed_" this is taking forever [07:47:19 CEST] <thebombzen> hm [07:47:40 CEST] <Speed_> xD [07:48:29 CEST] <Speed_> finnally [07:48:54 CEST] <grublet> time to go to LUDACRIS SPEED [07:51:12 CEST] <ac_slater> loll [07:56:21 CEST] <ac_slater> alright guys, I have to ask. If I'm creating an mpegts mux context (avformat_alloc_output_context2(fmt, NULL, "mpegts", NULL") and I add an H.264 video stream to it manually via avformat_new_stream(fmt,..). Do I have to change the "video_codec" field in the AVOutputFormat? It currently is set to AV_CODEC_ID_MPEG2VIDEO [07:56:32 CEST] <ac_slater> not sure if that value is used when I push packets into the muxer [09:16:52 CEST] <Speed_> https://hastebin.com/opulejajim.sql [11:51:20 CEST] <dystopia_> furq you still here [11:51:42 CEST] <dystopia_> i found an app to extract my subs to .srt [11:52:28 CEST] <dystopia_> now im doing "ffmpeg -i input.ts -i input.srt -c:v libx264 -an output.mp4 [11:52:58 CEST] <dystopia_> but it's trying to process the old dvb_subtitle and failing [11:53:14 CEST] <dystopia_> - [11:53:15 CEST] <dystopia_> Stream mapping: [11:53:16 CEST] <dystopia_> Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264)) [11:53:16 CEST] <dystopia_> Stream #0:2 -> #0:1 (? (?) -> ass (ssa)) [11:53:16 CEST] <dystopia_> Decoder (codec dvb_teletext) not found for input stream #0:2 [11:53:18 CEST] <dystopia_> :( [11:54:01 CEST] <dystopia_> i guess i can mux it in after the encode :| [12:03:54 CEST] <SolidusAbi> Hi, has someone experience with a VC1 encoder? I know VC1 is not supported in FFMPEG but I need some encoder which let me to work from command line... and you are my last hope. [12:38:08 CEST] <Threads> dystopia_ have you tried using -sn [12:41:46 CEST] <dystopia_> Threads i want the .srt subs to be included [12:42:01 CEST] <dystopia_> but i don't want the dvb_teletext and dvb_subtitle to be [12:42:18 CEST] <dystopia_> im just muxing it in after encode so it's ok, just a bit annoying [12:43:26 CEST] <c_14> dystopia_: -map 0:v -map 0:a -map 1:s [12:44:41 CEST] <dystopia_> thanks c_14 :) [12:45:44 CEST] <zerodefects> In the AVCodecContext data structure, what is the difference between 'thread_type' and 'active_thread_type'. The latest trunk docs don't elaborate too much. [12:47:55 CEST] <DHE> you can request one thread type, but ffmpeg is allowed to disregard it and do something different. maybe threading isn't enabled, maybe the number of threads select ended up as 0, etc. [12:49:29 CEST] <zerodefects> Thanks. Which one of those data members should I set? Both? [12:49:44 CEST] <DHE> set thread_type [12:51:01 CEST] <zerodefects> And if there is a logic problem where low delay is set in conjunction with threading, is the library capable of auto-correcting that and determing the best flags to use? [12:53:00 CEST] <zerodefects> ...just curious how much checking I need to do (ie. is the checking library side versatile). [13:07:46 CEST] <SolidusAbi> Hi, has someone experience with a VC1 encoder? I know VC1 is not supported in FFMPEG but I need some encoder which let me to work from command line... and you are my last hope. [13:28:17 CEST] <zerodefects> I can't get the mpeg2video encoder to call my custom execute/execute2 functions. I'm setting the thread_count to '4' and enabled threading for slice frames but to no avail. [15:14:57 CEST] <MarioMey> Hi, there. I'm trying to compile Blender, it asks for ffmpeg path. In previous Ubuntu distro (14.04), it was on/opt/lib/ffmpeg... but now, I don't find it. I want to clear some doubts, let's start with the first one: [15:16:36 CEST] <MarioMey> I installed Ubuntu-Mate 16.04... and then, kdenlive. In 14.04, I had libav, I used to use avconv. I know that I have that ffmpeg fork... but now, I'm not sure if I have ffmpeg and avconv as a kind of symbolic link of ffmpeg (because I have both commands) or viseversa. How should I know that? [15:17:25 CEST] <MarioMey> ffmpeg -version: [15:17:28 CEST] <MarioMey> ffmpeg version 2.8.11-0ubuntu0.16.04.1 Copyright (c) 2000-2017 the FFmpeg developers [15:17:41 CEST] <MarioMey> avconv -version [15:17:47 CEST] <MarioMey> ffmpeg version 2.8.11-0ubuntu0.16.04.1 Copyright (c) 2000-2017 the FFmpeg developers [15:17:50 CEST] <MarioMey> ffmpeg, so? [15:22:06 CEST] <MarioMey> Yes, it is like that. [15:22:15 CEST] <MarioMey> Now... where is ffmpeg path? [15:23:00 CEST] <DHE> if you're compiling blender, it wants the ffmpeg dev packages. headers and the like. [15:25:03 CEST] <MarioMey> DHE: what should the package name be? [15:25:41 CEST] <MarioMey> I'm viewing packages list in Synaptic... and I can't find ffmpeg-dev or similar. Also... I see a lot of livab libraries... :/ [15:25:50 CEST] <MarioMey> Don't understand why... [15:27:17 CEST] <MarioMey> I have libav-tools as transitional package... but I have libavcodec-extra, libavcodec-ffmpeg-extra56, livabcodec-ffmpeg56, etc... [15:27:19 CEST] <MarioMey> ?? [15:35:37 CEST] <BtbN> You need the ones ending in -dev [15:35:51 CEST] <BtbN> No idea if there is just ffmpeg-dev or something [15:36:02 CEST] <BtbN> And you shouldn't need to specify any special dir, as it will be in the default search path [16:54:24 CEST] <ac_slater_> hey guys [16:54:59 CEST] <ac_slater_> I'm struggling to create an input context and COPY one of the streams to an output context. Is this supported at all? [16:55:23 CEST] <JEEB> well as far as I know remuxing is supported [16:55:32 CEST] <JEEB> you will have to demux first of course [16:55:55 CEST] <ac_slater_> JEEB: right, I just want to basically copy all of the stream structure [16:56:09 CEST] <ac_slater_> I'll remux of course [16:56:38 CEST] <JEEB> under docs there should be examples [16:56:43 CEST] <JEEB> and then a remux example even [16:56:44 CEST] <ac_slater_> I'm just not about semantics when it comes to adding a stream to an AVFormatContext without using avformat_new_stream [16:57:02 CEST] <ac_slater_> would be awesome if there was avformat_add_stream(AVStream *) [16:57:15 CEST] <JEEB> there are various special cases of course :P but in general you have to do something similar to the remux example [16:57:41 CEST] <ac_slater_> I see. It's not updated to the 3.x api yet but it should be easy [16:57:44 CEST] <ac_slater_> thanks! [16:58:44 CEST] <JEEB> I have not checked how good this thing is but by its name it handles remuxing http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/remuxing.c;h=59… [16:59:08 CEST] <ac_slater_> oh awesome [16:59:37 CEST] <ac_slater_> that's kinda what I was getting at [16:59:43 CEST] <ac_slater_> was hoping there was a wrapper function ;) [16:59:54 CEST] <ac_slater_> but awesome, thanks JEEB [17:15:58 CEST] <zerodefects> In the AVCodecContext, any tips on what parameters I should set to get the mpeg2 video encoder to generate a bitstream as close to CBR as possible for use in say DVB/ATSC. There are a few parameters: bit_rate, rc_buffer_size, rc_min_rate, rc_max_rate, and there are some additional VBV settings too. [17:16:25 CEST] <ac_slater_> zerodefects: just really quick, you should first get `ffmpeg` (the command line tool [17:16:29 CEST] <ac_slater_> ) to do what you want [17:16:39 CEST] <ac_slater_> cause it'll save you lots of headache [17:17:41 CEST] <zerodefects> Ok. I'll try that. Thanks for the tip. Should it be relatively easy to translate that into code? [17:17:46 CEST] <ac_slater_> zerodefects: yea [17:18:04 CEST] <ac_slater_> mostly just passing in an AVDictionary into the output context [17:18:06 CEST] <JEEB> libx264 has a thing to add padding if needed [17:18:17 CEST] <JEEB> no idea how to make real CBR with mpeg2 encoder [17:18:30 CEST] <kepstin> ac_slater_: with the ffmpeg built-in codecs, it should pretty much just require setting bit_rate = rc_min_rate = rc_max_rate [17:18:42 CEST] <zerodefects> Ah ok. AVDictionary sounds the way to go. [17:18:43 CEST] <ac_slater_> kepstin: on the packet? context? [17:18:51 CEST] <kepstin> ac_slater_: on the context [17:19:05 CEST] <ac_slater_> ah right, I wasnt sure it had ALL of the options exposed outwardly [17:19:21 CEST] <kepstin> ac_slater_: and obviously you also need to set a rc_buffer_size value that's reasonable [17:20:10 CEST] <ac_slater_> kepstin: right (I see he says AVCodecContext not FormatContext) [17:20:59 CEST] <kepstin> I'm not sure whether you also have to put an option on the mpegts muxer to get it to pad packets out [17:21:31 CEST] <zerodefects> kepstin: You've hit the nail on the head, because I was setting all those including rc_buffer_size and then running into warnings: [17:21:41 CEST] <zerodefects> [mpeg2video @ 0x55dea1b8eaa0] Automatically choosing VBV buffer size of 224 kbyte [17:21:41 CEST] <zerodefects> [mpeg2video @ 0x55dea1b8eaa0] Warning vbv_delay will be set to 0xFFFF (=VBR) as the specified vbv buffer is too large for the given bitrate! [17:22:08 CEST] <kepstin> oh, oops, I was responding to the wrong person, sorry zerodefects :) [17:22:12 CEST] <zerodefects> So I was curious if there was a formula I could use :) [17:22:28 CEST] <zerodefects> No worries [17:22:55 CEST] <kepstin> zerodefects: it's not usually something you make up, but rather something specified by the standards for your target... [17:23:24 CEST] <zerodefects> So in the case of DVB, I ought to read the relevant docs? [17:26:17 CEST] <kepstin> as far as a rule of thumb, a good start for vbv values if you don't know otherwise is to multiply the bitrate by the keyframe interval [17:27:27 CEST] <kepstin> (e.g. with 5mbit/s video, 2s keyframe interval, then 10mbit vbv buffer size is probably a reasonable value) [17:27:44 CEST] <grublet> how could a buffer be "too large"? [17:27:49 CEST] <kepstin> but the exact value depends on the minimum specifications of the decoder [17:27:55 CEST] <grublet> or am i misunderstanding the reason of a buffer? [17:28:22 CEST] <kepstin> grublet: it's not that the buffer is too large, it's that one of the fields in the video header "vbv_delay" can't represent values for a vbv buffer over a certain size [17:28:32 CEST] <grublet> ah okay [17:28:37 CEST] <grublet> that makes sense then [17:29:44 CEST] <zerodefects> Thanks kepstin. Good to know. I'll investigate this further. Are there any OSS tools to check the video bitrate in my TS stream? [17:29:54 CEST] <kepstin> zerodefects: i dunno [17:30:44 CEST] <ac_slater_> zerodefects: to what extent? [17:30:46 CEST] <kepstin> btw, if you're getting that vbv warning when it picked a buffer size of only 224kbit (~1.7mbit), then you must be using a rather low bitrate? Make sure you're setting the bitrate in bits, not kbits :) [17:31:01 CEST] <ac_slater_> `mediainfo` or `ffprobe -show_streams` can show SOME things [17:31:26 CEST] <zerodefects> Ok thanks 'ac_slater' [17:31:43 CEST] <zerodefects> Yeah, I've set bitrate to '600000' [17:32:04 CEST] <zerodefects> So that's 600 kbps, right? [17:32:14 CEST] <zerodefects> it is very low! [17:32:17 CEST] <kepstin> lol, 600kbit mpeg2 is probably not enough for even sd video :/ [17:33:14 CEST] <zerodefects> The problem I had is that I was getting dropped packets running Ubuntu in virtual box, so I had reduced it drastically. [17:33:17 CEST] <zerodefects> :( [17:38:21 CEST] <kepstin> the automatically chosen vbv setting there ^^ is the correct value for DVD video, which is typically around 5-10mbit/s [17:39:20 CEST] <kepstin> note that DVD video uses an annoying low vbv buffer size because it's designed for really old, simple playback hardware. As a result, high motion stuff is basically impossible to encode for DVD such that it looks decent :/ [17:39:25 CEST] <grublet> the vbv is based on the data rate of the disc itself, right? [17:40:12 CEST] <kepstin> grublet: the vbv is based on the size of a ram buffer in the player hardware [17:40:29 CEST] <zerodefects> Ah ok [17:40:37 CEST] <grublet> kepstin: ok cool [17:41:35 CEST] <kepstin> for more modern usage, where you have pcs doing playback with effectively unlimited ram, you pick vbv values by multiplying the internet connection speed by the maximum amount of delay before video playback starts [17:42:48 CEST] <zerodefects> So let's say I'm going with 1Mbit/s in video, what would be a sensible vbv_delay? [17:43:35 CEST] <kepstin> zerodefects: it depends on your target player and how the video is being transferred to them. [17:44:22 CEST] <zerodefects> Ok. Should the vbv_delay be set through 'AVCPBProperties' struct? [17:44:50 CEST] <kepstin> zerodefects: you shouldn't be setting vbv delay, it should be automatically calculated from the stream bitrate and rc buffer size [17:45:07 CEST] <zerodefects> Ah right. That's some relief :) [17:45:11 CEST] <DHE> vbv_delay is only used by a small number of mpeg-based encoders anyway. libx264 and the like don't use it [17:45:46 CEST] <zerodefects> Thanks guys. [17:46:37 CEST] <zerodefects> Last field I had a question about was 'bit_rate_tolerance'. [17:46:56 CEST] <zerodefects> Can I just set that to equal bit_rate? [17:48:23 CEST] <kepstin> delay is just be buffer size divided by bitrate. That formula is often used backwards, e.g. "I want 2s of delay on a 5mbit/s stream, so I use 10mbit buffer" [17:49:39 CEST] <zerodefects> Ah ok. That's raises another question which I'll come back to after 'bit_rate_tolerance' [17:51:07 CEST] <kepstin> I dunno what a good value for tolerance is, but based on the code, somewhere around 5-20 times the bitrate seems reasonable? It'll override it to 5 * bitrate if you set it too small. [17:51:24 CEST] <kepstin> I dunno how much effect it has in "cbr" encoding [17:53:44 CEST] <zerodefects> Do you expect that the encoder may pad the bitstream if I try set CBR? [17:54:29 CEST] <ac_slater_> JEEB: quick question. Not sure if this is intended, but since AVCodecParameters doesnt have a time_base field, it seems like to make 2 streams appear identical, I have to copy stream->time_base manually. Is this intended? [17:55:59 CEST] <ac_slater_> It would kinda make sense since I have to make a new stream to copy into anyway, might as well set some fields while I'm at it. [17:56:04 CEST] <kepstin> zerodefects: I don't know if it will or not, you might have to set additional parameters on the muxer [17:57:18 CEST] <zerodefects> Correct me if I'm wrong, but there is stuffing that gets added in the TS and then padding that can be inserted at the elementary stream level? [17:57:55 CEST] <kepstin> zerodefects: I don't really do cbr stuff, I don't know :/ [17:58:34 CEST] <zerodefects> No worreis, you've been of great help :) [17:59:08 CEST] <zerodefects> The last question going back to vbv_delay. If I set low delay flag, does that effectively change/alter the vbv_delay in the encoder? [18:00:24 CEST] <kepstin> I don't think they have anything to do with each-other [18:00:53 CEST] <kepstin> I suspect it has something to do with frame ordering, stream syntax, and B-frames, but not really sure. [18:01:39 CEST] <kepstin> probably just completely disables b-frames [18:02:06 CEST] <zerodefects> Okay. I'll add that to my list to investigate. Thanks for your time and help. [18:02:20 CEST] <kepstin> you almost certainly don't want to disable b frames :) [18:03:02 CEST] <kepstin> only case that might be useful is stuff like extremely low latency video conferencing and whatnot [18:04:11 CEST] <zerodefects> yeah, I had noticed the flag so I was curious what affect it had on video and how it worked. [19:12:02 CEST] <marsrover> hi. im using ``ffprobe -v quiet -of flat -show_streams file.mkv`` to list all the streams in a file. is there any way i can alter the commandline to only show me the audio streams? [19:14:29 CEST] <marsrover> actually i got it.. add ``-select_streams a`` [19:14:35 CEST] <marsrover> thnks marsrover [19:18:41 CEST] <thebombzen> marsrover: you should -v error which will still print errors to stderr [19:19:02 CEST] <thebombzen> printing errors might be useful if you're trying to cobble something together for hanksville [19:20:07 CEST] <marsrover> dont think i need to bother. all im checking is if any audio tracks have >2 channels. just need a yes/no result.. or yes/not-yes [19:21:43 CEST] <thebombzen> marsrover: either way, you're looking for streams.stream.N.channels [19:21:47 CEST] <thebombzen> where N is the stream index [19:22:25 CEST] <thebombzen> which does depend on which index you use [19:23:37 CEST] <FlyingSolomon> Hello! [19:30:53 CEST] <thebombzen> FlyingSolomon: hello [19:55:10 CEST] <FlyingSolomon> I'm a bit confused actually, is there an updated api tutorial\example for ffmpeg? I've been trying to play with it to no a vail [19:56:26 CEST] <FlyingSolomon> everything that I found seems to be deprecated [20:00:33 CEST] <FlyingSolomon> (For the c library, not the cli tool) [20:05:06 CEST] <wlfgang> i know of the dranger tutorial, seems reasonably up to date: http://dranger.com/ffmpeg/ [20:05:59 CEST] <FlyingSolomon> from what I tried it seems to use a lot of deprecated stuff [20:06:34 CEST] <atomnuker> FlyingSolomon: https://github.com/atomnuker/cyanrip/blob/master/src/cyanrip_encode.c should be usable as an example [20:06:56 CEST] <FlyingSolomon> Ok, thanks :) [20:06:57 CEST] <atomnuker> it doesn't use anything deprecated and only encodes samples to file [20:07:07 CEST] <ac_slater_> guys please help. https://paste.debian.net/958800/ ... When I try to mux AVPackets into an mpegts output context, I see non-monotonic timestamp warnings [20:07:30 CEST] <ac_slater_> oh wait [20:08:04 CEST] <ac_slater_> I know the issue... [20:18:52 CEST] <ac_slater_> alright guys, I do have a serious issue [20:19:35 CEST] <ac_slater_> (pasting) [20:22:11 CEST] <wlfgang> i have the same question as FlyingSolomon more or less, what is there besides ffplay.c to illustrate a basic media player? [20:28:02 CEST] <thebombzen> wlfgang: ffplay.c is not a good example of a basic media player because it accepts a lot of ffmpeg-style options like -vf, -codec, etc. [20:28:32 CEST] <thebombzen> you'd have to basically ignore all the crap and then you could use it as an example [20:32:58 CEST] <wlfgang> my thoughts exactly, ffplay is pretty tough to wade through [20:33:19 CEST] <wlfgang> i have used the library for streaming, but now i am mainly interested in how to control playback speed for files [20:34:05 CEST] <thebombzen> wlfgang: mpv has a --speed= option, you could check out the code for that [20:34:23 CEST] <thebombzen> I'm not sure entirely how they do it. It's easier for video probably [20:34:43 CEST] <wlfgang> thanks, i'll check that out [20:35:34 CEST] <thebombzen> wlfgang: a primitive video player method is to use timestamps of the input and use some sort of milisecond sleep [20:35:45 CEST] <thebombzen> to play at halfspeed, you'd just double the sleeps [20:35:52 CEST] <thebombzen> audio is harder, and you'd probably have to use a filter [20:36:20 CEST] <thebombzen> a hacky-solution would be to pretend that 48 kHz raw audio is 24 kHz, but I'm not entirely sure how well that'll go down [20:36:48 CEST] <thebombzen> ah nvm that won't work, that'll cut the pitch in half, ignore me [20:38:06 CEST] <kerio> what does it even mean to slow down audio [20:38:56 CEST] <thebombzen> halve the tempo [20:39:07 CEST] <kerio> oh ;o [20:39:23 CEST] <kerio> ye ok but what about things that are not musical instruments [20:39:38 CEST] <thebombzen> it just means play it at half speed essentially [20:40:05 CEST] <kerio> oh so with halved pitch :3 [20:40:10 CEST] <thebombzen> audio is essentially just a wave, so if you stretch the wave by a factor of 2x, it would halve the pitch [20:40:16 CEST] <thebombzen> the hard part is to do that without halving the pitch [20:40:37 CEST] <kerio> you mean slow it down and then do unnatural things to double the pitch [20:40:50 CEST] <thebombzen> that would be a primitive way of doing it [20:40:57 CEST] <thebombzen> there are more advanced algorithms to achieve the result directly [20:41:16 CEST] <thebombzen> but this is theoretically what you are trying to accomplish, yes, but due to the discrete nature of digital audio it's not easy [20:41:58 CEST] <thebombzen> but yes you essentially want to play it half as fast but without dropping everything an octave [20:44:01 CEST] <FlyingSolomon> for what I know changing audio speed without changing pitch is considerably difficult [20:44:02 CEST] <FlyingSolomon> https://en.wikipedia.org/wiki/Audio_time-scale/pitch_modification [20:44:14 CEST] <furq> http://sbsms.sourceforge.net/ [20:44:18 CEST] <furq> that's what audacity uses [20:44:30 CEST] <furq> presumably that second section actually means something to some people [20:45:43 CEST] <FlyingSolomon> Ah they interpolate, interesting [20:46:23 CEST] <kerio> it's even awkward to imagine how to make it work [20:46:41 CEST] <kerio> for anything that's not a finite sum of sinusoids [20:47:04 CEST] <FlyingSolomon> well If you want real time I don't know it it's the right method, it seems expensive to me [20:47:28 CEST] <thebombzen> I've found that in practical listening tests, af_rubberband performs best [20:47:40 CEST] <thebombzen> at least better than af_atempo in libavfilter [20:47:49 CEST] <thebombzen> it just uses the librubberband external library [20:56:44 CEST] <kepstin> note that ffmpeg does have a filter that uses librubberband [20:57:29 CEST] <kepstin> er, wait, that's what you said :) [20:57:52 CEST] <furq> well if it didn't perform better then it'd have been removed [21:28:24 CEST] <CFS-MP3> ffprobe -show_frames -select_streams v 01-BBC1.EastEnders.ts -show_entries frame=pict_type,key_frame,pkt_pts -print_format compact=print_section=1|more [21:28:25 CEST] <CFS-MP3> displays [21:28:37 CEST] <CFS-MP3> frame|key_frame=0|pkt_pts=1091033010|pict_type=Bside_data|side_data_type=Active format description|side_data_size=1 [21:28:44 CEST] <CFS-MP3> how can I get rid if that side_data? [22:29:11 CEST] <ac_slater_> alright guys maybe this is a quick one. I have and mpegts muxer that supports some DATA formats. If I define some time_base for my data stream, what's the av* function to "increment" timestamps? ie - the PTS/DTS/DURATION deltas [22:42:09 CEST] <Hink> Are there any ffmpeg GUI tools that would help me quickly go through a large amount of video clips and trim them without re-encoding? [22:42:28 CEST] <Hink> Currently I have to preview the clip in VLC then cut it via the command line with ffmpeg. [22:42:38 CEST] <Hink> It's a little tedious. [22:44:33 CEST] <AndreKR> Hi [22:44:38 CEST] <AndreKR> I'm trying to encode using h264_qsv, but I'm getting "Error initializing the encoder: invalid video parameters (-15)". [22:44:44 CEST] <AndreKR> Command line: ffmpeg -i src.mp4 -c:v h264_qsv -preset:v faster -q 5 -look_ahead 0 -loglevel debug test.mp4 [22:44:54 CEST] <AndreKR> Full log output: https://pastebin.com/BNZyK0KA [22:44:58 CEST] <AndreKR> MediaSDK system analyzer: https://pastebin.com/kfxBQSkH [22:48:28 CEST] <AndreKR> That's with the Zeranoe nightly, but the same happens with 3.3.1. [22:55:29 CEST] <ac_slater_> furq: how much do you know about video clocks ;) [23:07:23 CEST] <ac_slater_> Alright maybe a better question. When I call `av_write_frame(ctx, packet);` what's the best way to increment the packet's PTS? And do I have need to rescale the timebase from packet to muxer OR does it do that automatically via av_write_frame? [23:30:16 CEST] <tiagobarreto> I'm using the ffmpeg in my iOS and android projects but I have a issue: https protocol not found, recompile FFmpeg with openssl, gnutls or securetransport enabled. I already to set the gnutls in project but the message don't appear and I cant to play my video using the https. Why? [23:31:51 CEST] <ac_slater_> tiagobarreto get it all compiled and working on linux/OSX first, then find what's different about the toolchains/target [23:34:01 CEST] <tiagobarreto> @ac_slater_ It's possible to check if the ffmpeg compiled is using the gnutls? [23:34:08 CEST] <ac_slater_> yea [23:34:16 CEST] <ac_slater_> couple things [23:34:29 CEST] <ac_slater_> tiagobarreto: running `ffmpeg` shows the ./configure line in the header [23:35:43 CEST] <tiagobarreto> @ac_slater_ thanks :) [23:35:43 CEST] <ac_slater_> tiagobarreto: or `ffmpeg -buildconf` [23:36:13 CEST] <tiagobarreto> It's better. [23:36:15 CEST] <ac_slater_> also look at the top of `ffmpeg -h`... you'll see -devices, -formats, etc [23:36:30 CEST] <ac_slater_> I think you'll find http support/capabilities SOMEWHERE in there [23:37:30 CEST] <tiagobarreto> hum.. great! [23:38:25 CEST] <ac_slater_> ffmpeg -protocols should list http if it works [23:39:00 CEST] <tiagobarreto> I think that the problem ocours because the ffmpeg installed in my machine is different used for https://github.com/Bilibili/ijkplayer library. So, when I compiled the ffmpeg the project in ios and android not updated. [23:39:38 CEST] <ac_slater_> maybe, I'm not sure [23:39:45 CEST] <ac_slater_> I think you can figure it out though ;) [23:39:55 CEST] <tiagobarreto> Because the ffmpeg -protocols listed the https. [23:40:46 CEST] <tiagobarreto> Yes, Thanks for help @ac_slater_ :) [00:00:00 CEST] --- Fri Jun 2 2017

1 0

ffmpeg-devel.log.20170531
by burek 01 Jun '17

01 Jun '17

[02:34:26 CEST] <cone-427> ffmpeg 03Michael Niedermayer 07master:78f6ec32a372: avformat/avidec: Fix txts fmts parsing [02:34:26 CEST] <cone-427> ffmpeg 03Michael Niedermayer 07master:a5d849b149ca: avformat/avidec: Limit formats in gab2 to srt and ass/ssa [02:34:26 CEST] <cone-427> ffmpeg 03Michael Niedermayer 07master:edf686f089d6: tests/fate/libavcodec: Test with all idct and dct modes supported in the test [08:14:04 CEST] <nadermx> so if I was to change the order of this line https://github.com/FFmpeg/FFmpeg/blob/a51867ee6bc717a54ea2436e31ee626f02fdf… and moved it to this line https://github.com/FFmpeg/FFmpeg/blob/a51867ee6bc717a54ea2436e31ee626f02fdf… would in theory fix the problem since it would then write the header before it starts the mp3, or am I missing something [11:10:04 CEST] <wm4> nevcairiel: a user is getting "Unable to decrypt message" with tls_schannel.c, any idea what could cause this? [11:11:58 CEST] <wm4> getting this somewhere around when a new connection is opened [11:12:15 CEST] <wm4> well, shortly after opening [11:14:07 CEST] <nevcairiel> maybe it should log the error code for debuging purposes [11:17:51 CEST] <nevcairiel> using schannel is q uite involved so i'm not discounting that there is a bug in there somewhere [11:21:47 CEST] <wm4> nevcairiel: like this? http://sprunge.us/ODTQ [11:23:12 CEST] <nevcairiel> what type is SECURITY_STATUS anyway [11:23:16 CEST] Action: nevcairiel looks it up [11:24:15 CEST] <nevcairiel> its long [11:24:17 CEST] <nevcairiel> interesting [11:25:46 CEST] <nevcairiel> i keep forgetting the rules, is it ok to cast a negative signed integer to unsigned and expect the bit patterns to just translate over? [11:26:27 CEST] <wm4> *shrug* [11:27:00 CEST] <nevcairiel> apparently it is [11:27:06 CEST] <nevcairiel> so its probably ok [11:29:59 CEST] <nevcairiel> for work I just decided to use gnutls on all platforms, its so extremely trivial to use compared to schannel (also, making 2-3 implementations didnt sound like fun) [11:30:55 CEST] <wm4> gnutls is generally a pain to build [11:31:04 CEST] <wm4> schannel has worked pretty well so far [11:31:09 CEST] <nevcairiel> it was ok [11:31:24 CEST] <wbs> openssl is even worse in one way though, majorly custom build system there [11:31:32 CEST] <wbs> (but that's not really an option for redistribution either) [11:31:38 CEST] <nevcairiel> i should thank wbs for pushing all sorts of projects to support gnutls/nettle instead of gcrypt, i found various patches or comments from him while dealing with this =p [11:31:51 CEST] <wbs> \o/ [11:32:34 CEST] <wbs> well it was mostly gnutls themselves that did the push. a lot of users of gnutls had to be updated to work properly when the backend changed though; IIRC I patched curl for this case at least [11:32:55 CEST] <wbs> (all that kind of downstream users of gnutls would have had to make the same change sooner or later in any case though) [11:32:57 CEST] <nevcairiel> from the top of my head i at least remember curl and librtmp [11:33:06 CEST] <wbs> ah, right, librtmp as well [11:34:59 CEST] <nevcairiel> we actually shipped both nettle and gcrypt for a while because the person who set this up didnt really know better, so was nice to clean this all up and unify it all into nettle [11:36:12 CEST] <wbs> setting up thread safety with gcrypt is a pain, although gnutls started abstracting that away at some point also (probably in the preparation for making their backend switchable) [12:18:35 CEST] <cone-787> ffmpeg 03wm4 07master:016023038217: videotoolbox: log errors [12:18:35 CEST] <cone-787> ffmpeg 03wm4 07master:3da13fd6acea: avformat/tls_schannel: log unknown error codes [12:58:46 CEST] <nevcairiel> man pushing sure has become slow [12:58:55 CEST] <cone-787> ffmpeg 03Martin Storsjö 07master:47c43ce36f0c: configure: Fix the msvcrt version check for mingw32 [12:59:59 CEST] <wm4> yes it has [13:02:13 CEST] <nevcairiel> should probably push that into 3.3 as well eh [13:04:42 CEST] <cone-787> ffmpeg 03Martin Storsjö 07release/3.3:1cbeb16187c8: configure: Fix the msvcrt version check for mingw32 [13:21:40 CEST] <pross_> sdf [13:21:57 CEST] <pross_> wrong window ah [15:21:44 CEST] <ubitux> we can make ps_hybrid_analysis so simple with simd it's crazy [15:24:29 CEST] <wm4> michaelni: would you consider fixing the timestamp logic in libavformat for h264 streams, which put the second field into their own packet (which AFAIK most containers prefer)? I think utils.c's logic breaks because it assumes one full frame per packet, so it assumes that the codec delay can be applied to packets directly (to me it looks like the packet delay is variable and depends which picture structures it contains) [15:36:31 CEST] <michaelni> wm4, i can look into it if i have a testcase for ffmpeg or ffplay. Might take a bit of time before ill look at it though, there seems an eternal stream of work i should work on [15:44:43 CEST] <wm4> I'll look for a sample, though it hsppens with common-place TV broadcast streams [15:47:48 CEST] <cone-787> ffmpeg 03Stefano Sabatini 07master:002dbc5a1f2a: examples/encode_video: add log [15:47:49 CEST] <cone-787> ffmpeg 03Stefano Sabatini 07master:ddae67945854: examples/encode_video: slightly improve error reporting [16:15:27 CEST] <cone-787> ffmpeg 03Michael Niedermayer 07master:58f8cd4ac576: avcodec/cavsdec: Fix runtime error: signed integer overflow: 59 + 2147483600 cannot be represented in type 'int' [16:15:29 CEST] <cone-787> ffmpeg 03Michael Niedermayer 07master:a1c0d1d906d2: avcodec/pnm: Use ff_set_dimensions() [16:15:29 CEST] <cone-787> ffmpeg 03Michael Niedermayer 07master:08cb69e870c1: avcodec/ra144: Fixes runtime error: signed integer overflow: 7160 * 327138 cannot be represented in type 'int' [17:27:22 CEST] <kwizart> hello, is there any releases schedule for ffmpeg branches (like what is done in the kernel for long time branch and EOL branches ?) [17:27:41 CEST] <kwizart> specifically asking for any ffmpeg 2.8.x [17:29:48 CEST] <BtbN> every once in a while a new one is made, if it's worth it [17:30:06 CEST] <BtbN> if no issues come up, or the release is too old to be maintained, none will come out anymore [17:32:16 CEST] <nevcairiel> new major relases are generally scheduled every 3 month, but depending on state of development that can slip - point releases in the branches are done on as-needed basis, and branches are dropped mostly when they get way too old and/or noone is really shipping it anymore [17:49:45 CEST] <jamrial> kwizart: 2.8.12 should be tagged/released soon [17:50:31 CEST] <jamrial> but in any case, you should consider upgrading to a newer version. 2.8 is pretty old by now [17:57:11 CEST] <kwizart> jamrial, thx, this is distro maintainer here (RPM Fusion for el/fedora), so newer releases are on ffmpeg 3.3 [18:40:31 CEST] <wm4> michaelni: sample, try remuxing to mkv, and once that works, remuxing mkv->mkv again: https://drive.google.com/file/d/0B3_rFvUatlX3QUpsUnM5REtmOXM/view (sorry for the shitty file hoster) [18:41:04 CEST] <wm4> I think for the initial ts->mkv remuxing I have a half-baked shithack [18:57:31 CEST] <durandal_1707> happy birthday [19:52:10 CEST] <kierank> durandal_1707: thanks [20:03:04 CEST] <J_Darnley> Does anyone have a tip for how I can force nasm to properly create "m %+ (8+i)"? [20:03:37 CEST] <J_Darnley> It ends up as m(8+0) though m(8+7) [20:11:08 CEST] <BtbN> was libnut recently removed from master or something? [20:11:49 CEST] <J_Darnley> I saw the patch on the ml, so probably it was applied if you're having some trouble. [20:11:53 CEST] <RiCON> it was [20:11:56 CEST] <BtbN> https://travis-ci.org/FFmpeg/FFmpeg-Coverity/builds/238027709?utm_source=em… [20:12:40 CEST] <BtbN> Guess I can remove schroedinger as well [20:21:18 CEST] <Gramner> J_Darnley: try "%assign %%tmp i+8", then "m %+ %%tmp" [20:21:47 CEST] <J_Darnley> Ah, basically work around the problem [20:22:51 CEST] <Gramner> well, it'd be more like working within the boundaries of the preprocessor expansion rules I guess [20:23:16 CEST] <Gramner> and preprocessor expansion rules always suck [20:23:25 CEST] <J_Darnley> :) [20:23:32 CEST] <J_Darnley> Well, that seems to work [20:33:36 CEST] <BBB> J_Darnley: uh, thats tricky stuff, have you considered asking gramner or loren? [20:34:09 CEST] <BBB> J_Darnley: you probably need to use xdefine or assign to explicitly generate the variable before concatenating it [20:34:20 CEST] <BBB> J_Darnley: I believe xdefine can do it, but gramner/pengvado would know for sure [21:29:01 CEST] <BBB> J_Darnley: have you looked at simple_idct10_template.asm? [21:30:12 CEST] <BBB> J_Darnley: so, first of all, I wouldnt necessarily reuse the code from the assembly you wrote earlier. its not that its bad code, but its highly optimized for a specific case where you do 4 coefficients per register (mmx) and then loop twice to get both halves of the transform finished [21:30:35 CEST] <BBB> J_Darnley: its really optimized for that case, but as such not very useful as a template for a full transform where we can do all coefs in a single reg pass (xmm) [21:31:22 CEST] <BBB> J_Darnley: simple_idct10_template.asm deals with the assumptions that were 64bit (>8 regs), can do all coefs in a single reg (16byte/xmm) and unfortuantely is 10-bit only right now [21:31:35 CEST] <BBB> J_Darnley: but as such it may be a good template for writing a xmm 8bit also [21:31:39 CEST] <BBB> (or at least example) [22:09:03 CEST] <thardin> one full week of fuzzing subtitles, no crashes uncovered [22:51:01 CEST] <J_Darnley> BBB: Thanks. I didn't thibk to look at the 10 bit assembly [22:51:12 CEST] <J_Darnley> *think [22:51:38 CEST] <BBB> its not immediately obvious that the two are related :) [22:52:15 CEST] <J_Darnley> I should know better. I've done the same h264 functions for both 8 and 10 bit [22:53:07 CEST] <BBB> i think youre being too hard on yourself atm... [23:16:22 CEST] <cone-347> ffmpeg 03Michael Niedermayer 07master:6726328f7940: avcodec/hevc_ps: Fix runtime error: signed integer overflow: 2147483628 + 256 cannot be represented in type 'int' [23:16:22 CEST] <cone-347> ffmpeg 03Michael Niedermayer 07master:e47057e932ff: avcodec/cinepak: Check input packet size before frame reallocation [23:16:22 CEST] <cone-347> ffmpeg 03Michael Niedermayer 07master:a47273c803ed: avcodec/wavpack: Fix runtime error: signed integer overflow: 2013265955 - -134217694 cannot be represented in type 'int' [00:00:00 CEST] --- Thu Jun 1 2017

1 0

ffmpeg.log.20170531
by burek 01 Jun '17

01 Jun '17

[00:00:05 CEST] <furq> is #3 still slow if you don't run anything on #1 [00:00:10 CEST] <aib> I guess it's two vCores to one physical core? [00:00:17 CEST] <furq> well one would hope so [00:00:51 CEST] <furq> but i don't see any guarantee that you're not getting physical cores shared with another instance [00:01:03 CEST] <aib> yes, core #3 is slow only when bogomips is running on core #1 [00:01:10 CEST] <furq> probably not that then [00:01:54 CEST] <aib> I'll check the other configurations but I'm guessing it will be #1 paired with #3 and 2 with 4 [00:02:00 CEST] <kepstin> hmm, if that's the case, then it looks like they're doing standard intel topology/thread numbering [00:02:34 CEST] <ppw> https://stackoverflow.com/questions/7274585/linux-find-out-hyper-threaded-c… [00:02:43 CEST] <ppw> "If hyperthreading is detected then lock the process to use the even-numbered logical processors only. This will make one of the two threads in each processor core idle so that there is no contention for resources." [00:03:02 CEST] <aib> furq: so there you have your answer. I'm much stupider :S [00:03:29 CEST] <furq> i'll take your word for it [00:03:42 CEST] <kepstin> the standard intel cpu numbering is for the first n/2 "cpus" to be the real cores, then the second n/2 "cpus" to be the hyperthread siblings corresponding to the first set of cpus [00:03:47 CEST] <aib> iive had it on the second guess [00:04:00 CEST] <aib> I've spent hours trying to figure this out. even wrote that stupid program for this :D [00:04:28 CEST] <aib> I always assumed it was a scheduling artifact [00:05:51 CEST] <kepstin> note that for video encoding with x264, I think there is a performance benefit to hyperthreading, so it's better to allow it to use hyperthread siblings rather than to lock it to physical cores [00:06:14 CEST] <kepstin> since it's memory intensive, i guess, so the cpu prefetchers can do a better job or something [00:10:27 CEST] <aib> hmm, I haven't tried multithreading within ffmpeg yet [00:11:09 CEST] <aib> (my application processes many segments at once, I have many more ffmpeg instances than cores, anyway) [00:12:51 CEST] <aib> by the way, 1-3 and 2-4 are siblings as expected. idle-priority thread on 1 slows down realtime-priority thread on 3 and vice versa :/ [00:13:19 CEST] <aib> ...but I don't even care that it's not harder to get the configuration I want. I have the answer to the riddle! [00:13:27 CEST] <aib> s/not/now [10:03:58 CEST] <Guest64222> Hello, [10:07:27 CEST] <Guest64222> I am trying to build a C shared library using ffmpeg, I am using ffmpeg's static libraries. I am facing a problem when trying to use a lib which depends on an other one, for example I can use libavresample.a but not libavcodec.a. If my shared lib uses libavcodec.a, Dllimporting it fails. If I remove calls to libavcodec.a functions, it works again [10:08:04 CEST] <Guest64222> Correction : "I can use libavutil.a but not libavcodec.a" [10:08:52 CEST] <Guest64222> any thoughts ? [10:30:51 CEST] <kam187> Hey guys I'm trying to enhance voice in a video using a lowpass and high pass filter [10:30:57 CEST] <kam187> is there any way to set the gain? [10:47:19 CEST] <oT2_> Do I have to includes shared libraries when using the static ones ? Every time I use a function of a static library which depends on an other ffmpeg lib, it fails [11:31:08 CEST] <zerodefect> I'm decoding some PAL content and then re-encoding using the "mpegts" format which outputs it to udp using the mpeg2video codec... [11:33:22 CEST] <Mavrik> Yay? :) [11:33:29 CEST] <zerodefect> The issue I'm experiencing is that there are some artifacts in the video when viewed through ffplay. The console output for ffplay indicates that "ac-tex damaged at xxx" and "Warning MVs not available". Any tips on how I can investigate the source of my errors. I'm using the C-API by the way, not console [11:33:56 CEST] <Mavrik> Do you have that issue if you store output to a file? [11:34:10 CEST] <zerodefect> Good question. Let me give that a go [11:34:18 CEST] <Mavrik> Usually it's a buffering issue [11:34:37 CEST] <Mavrik> Either you're overrunning the buffers somewhere (input in your API or output), have too high bitrate or the network is unreliable [11:36:53 CEST] <zerodefect> I think you're spot on. Playing output file through ffplay, no artifacts :) [11:37:13 CEST] <zerodefect> Interesting that my bitrate is only 600,000. That's nothing. [11:37:31 CEST] <zerodefect> Admittedly, I'm running Ubuntu Zesty in a VM hosted on Windows. [11:37:51 CEST] <Mavrik> Usually it's the player input buffer that's funny [11:37:58 CEST] <Mavrik> Also try using tcp :) [11:38:41 CEST] <zerodefect> Ah ok. For the record, I am timing the video so that the rate of transmission is same as the rate of playback. [11:38:55 CEST] <Mavrik> Hmm [11:39:01 CEST] <Mavrik> Are you compensating for bitrate spikes? :) [11:40:16 CEST] <zerodefect> Are you talking about in the video encoder? I haven't explicitly set CBR. I'm guessing, I can't control the buffering in the sender? [11:41:02 CEST] <Mavrik> Uhm... thing is... CBR is kinda rare when doing video [11:41:11 CEST] <Mavrik> I'm not sure if ffmpeg's MPEG-2 encoder really does true CBR [11:42:10 CEST] <zerodefect> Yeah, in transport streams there is usually stuffing that is introduced, right? [11:42:25 CEST] <Mavrik> Depends on use-case. [11:42:32 CEST] <Mavrik> Stuffing is really needed only for DVB-C/T [11:42:47 CEST] <Mavrik> For majority of cases it's silly because you're wasting expensive bandwidth with stuffing :) [11:43:10 CEST] <Mavrik> Better codecs (e.g. x264) actually rely on the fact that they can overrun bandwidth for awhile to get better quality. [11:44:07 CEST] <zerodefect> How can I use TCP to test. TCP is connection-oriented, so I need to establish a connection before sending/receiving, right? [11:44:26 CEST] <Mavrik> I think if you just do tcp:// and run ffplay first it'll work [11:44:40 CEST] <Mavrik> It's mostly just to test - it should show if your network is dropping packets or something [11:45:12 CEST] <Mavrik> But I'm pretty sure that uneven bitrate is at fault if you have an algoritem taking CBR into account when sending data [11:50:00 CEST] <zerodefect> Yeah, it's fine with TCP :) [11:50:20 CEST] <zerodefect> Awesome cheers. [11:51:16 CEST] <zerodefect> One last question...for now. I'm feeding the encoder a interlaced frame, but it looks to output a progressive frame (according to ffplay). [11:52:35 CEST] <Mavrik> zerodefect, check if your AVFrame is marked as interlaced before encoding [11:52:55 CEST] <Mavrik> zerodefect, and make sure you enable interlaced encoding [11:53:13 CEST] <Mavrik> codec_context->flags |= (CODEC_FLAG_INTERLACED_DCT | CODEC_FLAG_INTERLACED_ME) on older, no idea what's it now with codecpar [11:53:56 CEST] <Bruutal> i have 200,000.00 dollar to invest. what should i invest on? [11:56:30 CEST] <zerodefect> Mavrik, I'll investigate that. I'm not setting any of those flags. Many thanks for your help :) [11:56:48 CEST] <Mavrik> Also make sure the frame is actually interlaced :P [11:56:59 CEST] <Mavrik> encoder won't interlace it for you ;P [11:59:34 CEST] <zerodefect> yeah, just checked. 'interlaced_frame=1' and 'top_field_first=1' [12:05:11 CEST] <zerodefect> Got interlaced going. Checked the output (not into much detail), and it looks right on preliminary inspection. [12:06:56 CEST] <zerodefect> Mavrik, do you think that it's the spikes in the video bitrate that causes the receiver's buffers to overflow? [12:07:26 CEST] <Mavrik> I'd first check the network, VM network drivers can be wonky. [12:11:07 CEST] <zerodefect> Ok. Thanks [16:07:51 CEST] <Diego_> Hi there. I have a question about ffmpeg, as I'm using it for compiling audio and video sources into a one single video file. Anyone that could help me? [16:09:27 CEST] <celyr> combining ? [16:10:38 CEST] <Diego_> Yes, but I'm facing a different problem right now. I will try to explain myself as much as possible [16:12:28 CEST] <Diego_> Well, what I'm doing right now, as I said, is compiling an audio and video into a single video file. The problem right now is that I record video and audio, simultaneously, from different sources. What I should do now is to combine them into different files. E.g: I have 2 sources, which generates 4 files (2 audios and 2 videos). When I combine them, I get 2 video files. What I want to achieve now is to combine those 2 output videos int [16:13:23 CEST] <Diego_> "2 windows" in a single video, not just concatenate both [16:14:25 CEST] <Diego_> I don't know if that is possible with FFMpeg [16:16:53 CEST] <Diego_> I don't know if its quite clear [16:24:46 CEST] <BtbN> do you mean a mosaic? [16:25:32 CEST] <Diego_> Yes [16:31:44 CEST] <durandal_1707> its FFmpeg [17:01:35 CEST] <dantedevil> Hi, i've a problem with motion. I have a Rasperri Pi3 and 3 Ipcam. Now i have 2 error looking my motionlog file. [17:01:54 CEST] <dantedevil> [0:av1] [ERR] [ENC] [May 31 16:31:54] ffmpeg_avcodec_log: cabac decode of qscale diff failed at 56 13 [17:01:54 CEST] <dantedevil> [0:av1] [ERR] [ENC] [May 31 16:31:54] ffmpeg_avcodec_log: error while decoding MB 56 13, bytestream 397 [17:01:54 CEST] <dantedevil> [0:av2] [ERR] [ENC] [May 31 16:32:17] ffmpeg_avcodec_log: left block unavailable for requested intra mode at 0 24 [17:01:54 CEST] <dantedevil> [0:av2] [ERR] [ENC] [May 31 16:32:17] ffmpeg_avcodec_log: error while decoding MB 0 24, bytestream 1168 [17:02:05 CEST] <dantedevil> someone can help me [17:02:09 CEST] <dantedevil> ?? [17:39:09 CEST] <PlanC> I'm streaming the output of ffmpeg to a browser and I can't get the duration to show properly [17:39:52 CEST] <PlanC> since ffmpeg adds the duration once the entire file has been processed (since it doesn't know the duration before that) I'm having to specify it before based on the input length [17:39:58 CEST] <PlanC> my command looks like this: [17:40:39 CEST] <PlanC> ffmpeg -i video.mp4 -i audio.mp3 -c copy -metadata duration='00:01:00.00' output.mkv [17:40:56 CEST] <PlanC> now this actually sets the duration to 1 minute in VLC [17:41:14 CEST] <PlanC> but the problem is that as soon as I seek in the video, the VLC player crashes [17:41:36 CEST] <PlanC> anyone know how I can stop that from happening? [17:41:48 CEST] <BtbN> you can't seek in a live stream [17:42:09 CEST] <BtbN> and a regular mkv file is invalid before the final "lead-out" has been written [17:42:11 CEST] <PlanC> it's not a live stream though [17:42:21 CEST] <BtbN> it is, if you try to play it before the file is done [17:42:35 CEST] <BtbN> How the hell does it even take that long to do so with -c copy? It should be done in an instant [17:42:53 CEST] <PlanC> it's not taking long [17:43:14 CEST] <PlanC> I'm just streaming it before it ends [17:43:29 CEST] <PlanC> so it doesn't have to wait 20-30 seconds before the download starts in the browser [17:43:46 CEST] <BtbN> Use hls/dash for live streaming. [17:44:04 CEST] <PlanC> hls/dash? [17:44:06 CEST] <BtbN> I also don't think mkv is supported by browsers universally. Only safe bet is mp4 [17:44:13 CEST] <PlanC> so like separate video and audio? [17:50:17 CEST] <PlanC> the reason I chose mkv is that it's really fast [17:50:33 CEST] <PlanC> the speed is around 40x-50x [17:50:52 CEST] <PlanC> but with mp4 it's at 2x-3x [17:52:27 CEST] <PlanC> BtbN, is there any way to replicate the "lead-out" from the start? [17:52:32 CEST] <BtbN> no [17:52:38 CEST] <PlanC> what does it consist of? [17:53:04 CEST] <PlanC> because I'm looking at the metainfo in VLC and the only things missing are the bitrate and duration [17:54:46 CEST] <BtbN> a lot of things, like the duration, the seekhead with information on how to seek in the file(offets to specific frames), track masters [17:55:27 CEST] <BtbN> if the seekhead is missing, the file cannot be seeked in [17:55:37 CEST] <furq> what browser are you even playing mkv in [17:55:38 CEST] <PlanC> the strange thing is that some of the mkv files work perfectly with just the "-metadata duration='00:01:00.00'" [17:55:41 CEST] <furq> it's not supported in any without plugins afaik [17:55:43 CEST] <PlanC> and I can even seek in those videos [17:55:46 CEST] <BtbN> furq, I think firefox play it just fine [17:55:50 CEST] <PlanC> but for some other files it just crashes [17:55:59 CEST] <PlanC> I'm not playing them in the browser though [17:56:02 CEST] <PlanC> I'm playing them in VLC [17:56:02 CEST] <BtbN> The ones that are actually finished are obviously working [17:56:09 CEST] <PlanC> none of them are finished [17:56:14 CEST] <furq> 16:39:08 ( PlanC) I'm streaming the output of ffmpeg to a browser and I can't get the duration to show properly [17:56:15 CEST] <PlanC> all are streamed [17:56:39 CEST] <BtbN> you have to set -live 1 if you want to stream mkv. [17:56:41 CEST] <PlanC> furq: as in streaming the data to the browser's file manager [17:57:16 CEST] <PlanC> I'll try -live 1 and see how it goes [17:57:19 CEST] <BtbN> Also, what the hell do you expect to happen if you instruct a player to seek to a segment that has not been streamed yet? [17:57:34 CEST] <BtbN> If you stream, there is no duration, and no seeking. [17:57:39 CEST] <BtbN> If you want those, use finalized files. [17:57:43 CEST] <PlanC> no no [17:57:50 CEST] <PlanC> the file is only played once the entire file is downloaded [17:58:04 CEST] <BtbN> ?! [17:58:11 CEST] <BtbN> You are making no sense to me [17:58:21 CEST] <PlanC> how do I explain [17:58:53 CEST] <BtbN> if you want to play a video in a browser, use mp4 and maybe set -movflags faststart [18:00:11 CEST] <PlanC> as soon as ffmpeg starts processing the file and provides an output file [18:00:16 CEST] <PlanC> e.g output.mkv [18:00:34 CEST] <PlanC> I'm starting to download chunks from that output.mkv and sending it to the browser's download manager [18:00:49 CEST] <PlanC> once ffmpeg is finished and every single chunk of output.mkv is sent [18:00:52 CEST] <PlanC> I play the file in VLC [18:00:53 CEST] <BtbN> you can't do that [18:00:58 CEST] <PlanC> well it's working [18:01:01 CEST] <PlanC> but I can't seek [18:01:07 CEST] <BtbN> ffmpeg seeks back to the beginning of the file at the end, and writes the trailer. [18:01:11 CEST] <PlanC> working as in video plays [18:01:14 CEST] <PlanC> exactly [18:01:17 CEST] <BtbN> So the chunks you sent are dummy-chunks, resulting in an invalid file. [18:01:17 CEST] <PlanC> that's my problem [18:01:31 CEST] <PlanC> the video plays perfectly in windows media player [18:01:32 CEST] <PlanC> and mpc [18:01:34 CEST] <PlanC> but not VLC [18:01:44 CEST] <BtbN> It's an invalid file, it's pure luck. Don't do that. [18:01:55 CEST] <PlanC> it's worked on a whole bunch of files though [18:01:59 CEST] <PlanC> I've tried 10-15 files [18:02:06 CEST] <BtbN> Generate it with -live 1 if you want to be able to do that. Will remove seeking/duration. [18:02:23 CEST] <kepstin> Well, it's not really super invalid, it just will be missing the seek info because ffmpeg has to go and add that at the end. [18:02:32 CEST] <PlanC> I really need the seeking though [18:02:36 CEST] <kepstin> So if the player can seek without an index, it'll be seekable (but slow) [18:02:40 CEST] <BtbN> don't send an unfinished file then [18:03:06 CEST] <PlanC> yeah if I only could find a way to have that trailer added from the start [18:03:08 CEST] <BtbN> kepstin, it will have markings that those things exist, but have dummy data in its place. Hence a player reading this might do unexpected things. Or crash. [18:03:21 CEST] <BtbN> PlanC, the information needed for it are not known until the whole file has been generated. [18:03:27 CEST] <BtbN> It has to be the last thing written. [18:03:35 CEST] <PlanC> the only thing that isn't known is the duration, right? [18:03:50 CEST] <BtbN> And all the segment offsets to generate the seekhead. [18:04:02 CEST] <BtbN> Which is, as the name might suggest, what makes the file seekable. [18:04:22 CEST] <PlanC> how difficult would it be to add the seekhead manually? [18:04:30 CEST] <BtbN> from what? [18:04:33 CEST] <PlanC> it's fine if it's off for 1-2 seconds [18:04:43 CEST] <PlanC> based on the input file [18:04:44 CEST] <BtbN> You don't have the neccesary information before the file is done. [18:04:58 CEST] <furq> just use mpegts [18:05:23 CEST] <BtbN> Just finalize the file before you start downloading it, I don't get it?! [18:05:45 CEST] <PlanC> BtbN, but that would require me to wait until ffmpeg is done before I can start streaming [18:05:47 CEST] <furq> i've given up on trying to understand what's actually happening [18:05:56 CEST] <BtbN> you do that one time, and then offer the converted file. [18:06:00 CEST] <furq> but mpegts will probably do what you want it to do [18:06:12 CEST] <BtbN> mpegts is not seekable to begin with [18:06:27 CEST] <kepstin> PlanC: you might be able to do some horrible hack where you skip the first few chunks in your dynamic download system, then only send them after ffmpeg has exited :/ [18:06:33 CEST] <PlanC> furq, mkv is supported by more players though [18:06:34 CEST] Action: kepstin wouldn't recommend actually doing that [18:06:59 CEST] <BtbN> What you are asking for is technically impossible, no matter how hard you try to argue. [18:07:11 CEST] <PlanC> it's so close to working though [18:07:16 CEST] <BtbN> Convert the file ahead of time. [18:07:24 CEST] <PlanC> I've literally got it working in all players I've tested except vlc [18:07:45 CEST] <BtbN> you can't get seeking working, as the seekhead has not been written. [18:07:47 CEST] <kepstin> PlanC: well, "working", in that the other players have a slow fallback seek ability if there's no index available [18:08:02 CEST] <PlanC> kepstin: but most players have that right [18:08:10 CEST] <PlanC> (except VLC) [18:08:16 CEST] <kepstin> sure, but you shouldn't rely on it. [18:08:20 CEST] <BtbN> Why are you making your life that hard? Just store the converted file. [18:08:48 CEST] <ritsuka> please don't create more broken files, there are already enough out there. So many hacks just to keep things working& [18:09:03 CEST] <PlanC> BtbN: but that would require ffmpeg to finish first leading to a bunch of wasted time [18:09:15 CEST] <BtbN> So run it ahead of time, not on the last second? [18:09:24 CEST] <PlanC> what do you mean? [18:09:26 CEST] <BtbN> You said your content is not live, so what's the issue with that? [18:09:51 CEST] <kepstin> is this user-uploaded media? I guess you're trying to reduce turn-around time [18:09:59 CEST] <PlanC> but ffmpeg would have to finish completely and then I could start sending the chunks [18:10:01 CEST] <PlanC> kepstin, yeah exactly [18:10:21 CEST] <kepstin> PlanC: if you want to send stuff streaming or in chunks, then use a streaming/chunked format [18:10:23 CEST] <PlanC> kepstin, it's a real waste of time to have them wait 20-30 seconds before the download starts [18:10:43 CEST] <kepstin> consider doing something crazy like doing a remux into mkv in javascript in the browser :/ [18:10:44 CEST] <BtbN> good luck with your brokenness then, I'm out of idea what else to tell you. [18:10:44 CEST] <furq> it's also a waste of time if you send them a broken file [18:10:48 CEST] <PlanC> kepstin, which formats are "streamable"? [18:11:11 CEST] <BtbN> mkv with -live 1, mpegts, hls, dash, fragmented mp4, ... [18:11:11 CEST] <kepstin> PlanC: mpegts, any segmented format, mkv without a seek index. [18:11:27 CEST] <BtbN> All of them are not seekable by definiton. [18:11:33 CEST] <BtbN> And have no inherent duration [18:11:42 CEST] <BtbN> you can't have both. [18:12:15 CEST] <furq> vlc should at least be able to seek in mpegts because it's expecting there to be no index [18:12:24 CEST] <furq> it'll be slow, obviously [18:12:39 CEST] <PlanC> both are needed though [18:12:54 CEST] <PlanC> video without capability to seek is pretty much useless no? [18:13:12 CEST] <BtbN> You can bash your head against that wall as much as you like. Not possible. [18:13:13 CEST] <kepstin> PlanC: I dunno how exactly you're building/saving the file, but if you can seek in the saving code then just go back and update the start of the file after ffmpeg has exited :/ [18:13:42 CEST] <BtbN> kepstin, he's offering them for download, and starts the download before the file is done... [18:13:53 CEST] <PlanC> yeah [18:14:09 CEST] <PlanC> so the bytes that are sent to the browser and out of my control [18:14:10 CEST] <kepstin> if it's just going through the browser, then yeah, the only solution is a time machine [18:14:11 CEST] <PlanC> I can't change those [18:14:17 CEST] <Fenrirthviti> Why are you not storing them already converted? That's just crazy [18:14:27 CEST] <kepstin> and if you had one of those, presumably you wouldn't be asking us about this [18:14:33 CEST] <Fenrirthviti> Trying to remux as part of a download operation is insane [18:14:39 CEST] <PlanC> Fenrirthviti, storage restrictions [18:14:55 CEST] <BtbN> again, it's simply not possible, nothing else to tell you. [18:15:08 CEST] <Fenrirthviti> Store in a better format with better compression then? [18:15:21 CEST] <Fenrirthviti> This sounds like the worst possible way to work around storage restrictions. [18:15:36 CEST] <furq> i still have no idea what's actually happening here [18:15:47 CEST] <furq> the best thing i can come up with is some kind of website that remuxes to mkv [18:15:58 CEST] <BtbN> someone is upset that pigs can't fly. [18:16:05 CEST] <furq> well yeah i got that much [18:16:10 CEST] <Fenrirthviti> There's a whole lot of pieces to this story missing. [18:16:14 CEST] <furq> but i want to know why [18:16:17 CEST] <Fenrirthviti> Like, why the source files just can't be offered for download? [18:16:18 CEST] <furq> i won't be able to sleep at night [18:16:43 CEST] <BtbN> furq, I think he's trying to build a custom YouTube, but wants to offer the video for playback absolutely immediately? [18:17:09 CEST] <kepstin> if it was just for playback, they'd use HLS or something, which is (sort of) seekable immediately while streaming :/ [18:17:19 CEST] <furq> two of the selling points of youtube, at least for me, are that it stores the video and that it plays the video in the browser [18:17:23 CEST] <furq> so i don't think that's it [18:17:31 CEST] <kepstin> it's the "download an mkv file as it's being encoded" that's the problem here. [18:17:36 CEST] <BtbN> Not even HLS/DASH is seekable immediately. The playlist with duration information is written at the very end as well [18:18:17 CEST] <kepstin> BtbN: you could hack it by pretending to be a live stream until the full encode is done, i guess. [18:18:37 CEST] <BtbN> But he insists on it being seekable right away. [18:18:44 CEST] <BtbN> Which is outright impossible [18:18:50 CEST] <kepstin> but the usual solution to this is to segment the file before encoding and throw ridiculous amounts of computing hardware to encode the video quickly. [18:18:57 CEST] <PlanC> what's kind of weird is that I can't just add the trailer to the end of the file [18:18:58 CEST] <kepstin> then you get fast turnaround and complete files [18:18:59 CEST] <furq> is he even encoding it [18:19:02 CEST] <furq> i thought he was copying [18:19:05 CEST] <PlanC> I really can't figure out why that isn't possible [18:19:22 CEST] <Fenrirthviti> because that's not how it works. [18:19:23 CEST] <kepstin> PlanC: the trailer is added at the end, but it has to go back and stick a value in the header to tell the player where to find the trailer [18:19:26 CEST] <BtbN> furq, even without encoding, the muxer still only has the required information when all packets are muxed [18:19:30 CEST] <furq> well yeah [18:20:05 CEST] <Fenrirthviti> The headers are read already by the player, so when it gets added later, the file would have to be reloaded which sounds like it's defeating the whole point of this endeavor, whatever that may be [18:20:30 CEST] <Fenrirthviti> I think storing the files better in the first place is the better solution :\ [18:20:53 CEST] <PlanC> storage limit otherwise I would [18:21:10 CEST] <Fenrirthviti> so your source is a live stream? [18:21:13 CEST] <Fenrirthviti> or what here? [18:21:18 CEST] <PlanC> no [18:21:31 CEST] <PlanC> it's for college [18:21:32 CEST] <Fenrirthviti> I'm confused why you can't just offer the original source file and why you need to remux then [18:21:45 CEST] <kepstin> PlanC: in these days of amazon giving out terabytes of storage for cents, a storage limit seems ridiculous :/ [18:21:53 CEST] <furq> for cents per hour [18:21:57 CEST] <PlanC> we have a huge ton of recorded lecture material which is stored with separate audio and video [18:22:25 CEST] <Fenrirthviti> Ah ha. [18:22:29 CEST] <PlanC> it's good to play online but if you want to play it locally on a video player it gets annoying [18:22:35 CEST] <furq> oh shit we're getting somewhere [18:22:44 CEST] <Fenrirthviti> See, now things are starting to make more sense, sort of [18:22:48 CEST] <PlanC> this is why I want to combine them and stream on the fly [18:22:57 CEST] <furq> in this case the sensible thing to do is remux it all to mp4 and delete the originals [18:23:05 CEST] <kepstin> PlanC: then... remux to mp4 and throw out the originals? then it'll play in both browser and download [18:23:11 CEST] <furq> ^5 [18:23:19 CEST] <Fenrirthviti> which is what I said 15 minutes ago \o/ [18:23:27 CEST] <furq> you must have one of those crystal balls [18:23:32 CEST] <PlanC> the data is huge though [18:23:38 CEST] <PlanC> several TB [18:23:40 CEST] <furq> it'll be exactly as huge after it's remuxed [18:23:49 CEST] <Fenrirthviti> remux shouldn't really change size much, if at all [18:23:57 CEST] <PlanC> all on a really weak processor that is just designed to do i/o [18:24:03 CEST] <furq> the processor doesn't matter [18:24:07 CEST] <furq> you're remuxing [18:24:18 CEST] <Fenrirthviti> it's a disk speed operation at that point [18:24:19 CEST] <PlanC> won't that take an insane amount of time to do? [18:24:29 CEST] <kepstin> of course, this depends on the codecs in the original files [18:24:35 CEST] <furq> if it's h264 video and aac/mp3 audio then no [18:24:40 CEST] <kepstin> if they're something that can't be muxed into mp4 then this'll be harder [18:24:57 CEST] <kepstin> but if the codecs are ok, then just use -c copy and be happy. [18:25:07 CEST] <furq> and if it's not h264 video and aac/mp3 audio then you should go to a different college [18:25:31 CEST] <Fenrirthviti> I'd even remove the /mp3 from that statement at this point :P [18:25:38 CEST] <furq> but yeah the overhead of muxing to mp4 should be well under 1% [18:25:50 CEST] <furq> even less if the originals are already in m4v/m4a [18:26:40 CEST] <PlanC> not sure what to do really [18:26:54 CEST] <BtbN> Convert the whole collection to faststarting mp4. [18:26:54 CEST] <PlanC> the best solution would be the mkv solution since the videos actually do play [18:27:13 CEST] <BtbN> You can get rid of the originals once that's done [18:27:21 CEST] <Fenrirthviti> That's actually the worst solution, not sure why you think it's the best [18:27:26 CEST] <BtbN> In theory even while it's running, but I'd want to verify that all the conversions worked. [18:27:29 CEST] <Fenrirthviti> and that will never work, as has been stated several times. [18:27:55 CEST] <furq> i'd be happy if you went with the mkv solution if you went on a campaign to ban vlc on your campus [18:27:55 CEST] <kepstin> unless you have Fenrirthviti's crystal ball, to read the mkv headers before they're written :/ [18:28:00 CEST] <PlanC> it does work although it relies on the fallback of the video players as you said [18:28:06 CEST] <furq> that would be a sacrifice worth making [18:28:26 CEST] <BtbN> it's incredibly broken, just don't do that. [18:28:48 CEST] <PlanC> wouldn't it be possible to somehow move the headers to the end of the file and have line in the start that points to them? [18:29:00 CEST] <furq> yes [18:29:06 CEST] <PlanC> so I'd have the trailer and all other data in the end [18:29:06 CEST] <kepstin> PlanC: that's exactly what happens already [18:29:07 CEST] <furq> you do that by waiting until the mkv has been finished [18:29:24 CEST] <Fenrirthviti> -c copy -movflags +faststart out.mp4 problem solved '.')b [18:29:25 CEST] <kepstin> PlanC: but you have to update the field at the start once you find out where the end bit is, so the player can find it [18:29:26 CEST] <PlanC> but when it finishes it adds it to the start not the end, right? [18:29:53 CEST] <kepstin> PlanC: by default it's added at the end, but the poiner at the start can't be set until you know where "the end" is [18:29:54 CEST] <Fenrirthviti> If you start playing it before the file is finalized, it will never work [18:29:56 CEST] <Fenrirthviti> no matter what you do. [18:30:06 CEST] <furq> how are you going to access the end of the file if the entire point of this is that you don't want to wait until the file has finished being written [18:30:25 CEST] <Fenrirthviti> You would have to close and reopen the file after the files are finalized, which is not something you will have control to do if you're playing it in a local player [18:31:12 CEST] <PlanC> but I wonder if it'd be possible to estimate where the end is based on the input audio and video [18:31:22 CEST] <furq> sure it would [18:31:26 CEST] <furq> but ffmpeg doesn't do that [18:31:32 CEST] <furq> you'd have to write your own remuxer [18:31:32 CEST] <PlanC> I'm just copying the data into the mkv and file size is usually input video + input audio [18:31:36 CEST] <kepstin> PlanC: just batch remux all your files. done. :/ [18:31:47 CEST] <furq> also yeah why did you just ignore the thing we all said you should do [18:32:02 CEST] <PlanC> you mean remuxing all the files? [18:32:05 CEST] <furq> yes [18:32:39 CEST] <Fenrirthviti> Let's start here... What is the format of the original video and audio files? [18:33:17 CEST] <PlanC> webm [18:33:27 CEST] <PlanC> both audio and video [18:33:42 CEST] <furq> are these dash fragments [18:33:44 CEST] <Fenrirthviti> webm is a container, what's inside it? [18:33:50 CEST] <kepstin> ... well, that's annoying, but it means you just have to remux them into webm. no real problem. [18:34:03 CEST] <kepstin> webm is only allowed to contain vp8, vp9, vorbis, and opus [18:34:15 CEST] <furq> if they're dash fragments then there's a corresponding playlist which any decent media player will play back [18:34:24 CEST] <Fenrirthviti> true, I guess it doesn't matter at that point. [18:34:43 CEST] <Fenrirthviti> but remuxing to webm isn't that big of a deal [18:34:51 CEST] <furq> even if they're not you could presumably just generate a dash manifest for each [18:35:18 CEST] <PlanC> some of the files are inactive so it would also be a waste to process those as well [18:35:24 CEST] <kepstin> PlanC: but if both inputs are just plain webm files, then 'ffmpeg -i video.webm -i audio.webm -c copy combined.webm' will be superfast and make you a single webm with both audio and video, which can be downloaded or used in the browser. [18:35:32 CEST] <kepstin> then delete the original separate webms, done. [18:36:17 CEST] <Fenrirthviti> most everything these days should play webm, so you don't need to convert to mkv or anything [18:36:45 CEST] <kepstin> note that webm is basically a ... profile? ... of matroska with the codecs permitted limited - most players support both [18:37:46 CEST] <Fenrirthviti> That actually reminds me, I was going to do latency tests with streaming webm through icecast [18:38:02 CEST] <Fenrirthviti> Gotta find a low-latency replacement for stinking rtmp one of these days :x [18:38:03 CEST] <furq> PlanC: do you have .mpd manifests for each of these lectures [18:38:17 CEST] <furq> or is it just one webm for video and one for audio per lecture [18:38:40 CEST] <furq> if you have manifests then vlc/mpv etc should be able to play those directly [18:40:51 CEST] <PlanC> no manifests [18:40:56 CEST] <PlanC> just a bunch of webm files [18:41:04 CEST] <furq> shame [18:41:12 CEST] <furq> i would recommend just creating manifests instead of remuxing [18:41:21 CEST] <furq> since that'd be non-destructive and quicker [18:41:43 CEST] <PlanC> do audio files also act in the same way? [18:41:45 CEST] <furq> but idk of a tool that generates them for existing videos (maybe ffmpeg does?) and apparently vlc stable doesn't play them back [18:41:52 CEST] <furq> you'd need vlc beta [18:42:04 CEST] <furq> and if this is for anyone on campus to use then that's probably a non-starter [18:42:41 CEST] <PlanC> I'll actually try vlc beta on the non-seekable mkvs and see if it works [18:42:55 CEST] <furq> that was not what i was hoping you'd take away from this, but ok [18:42:58 CEST] <BtbN> they are not non-seekable, they are broken. [18:43:19 CEST] <BtbN> I don't get your obsession with a "solution" that has been pointed out as bad and broken to the bone multiple times. [18:43:45 CEST] <kepstin> i mean, ffmpeg does try to make them broken in a way that they're still playable, so you can preview/recover incomplete encodes, but still. [18:44:04 CEST] <BtbN> It will write a dummy pointer to the header at the end [18:44:09 CEST] <BtbN> and no indication it is missing [18:44:17 CEST] <BtbN> what happens with that is not well defined [18:44:26 CEST] <BtbN> VLC seems to just try to seek there, and in turn crash [18:44:28 CEST] <PlanC> I know it's not an orthodox way of doing it [18:44:39 CEST] <PlanC> but if all the players are able to play the video then why not? [18:44:40 CEST] <BtbN> There have been numerous proper ways pointed out... [18:44:53 CEST] <BtbN> Because it's broken and can randomly fail at any point. [18:45:04 CEST] <PlanC> they require processing of all the files beforehand though(?) [18:45:10 CEST] <BtbN> yes, so? [18:45:28 CEST] <BtbN> Ever seen what YouTube does? Sometimes for days before a video goes live? [18:45:35 CEST] <PlanC> I also tried vlc beta and it's surprisingly able to seek in the broken mkvs [18:45:57 CEST] <BtbN> Seems like they fixed the crash then, but it can't seek properly, it's just technically impossible [18:45:57 CEST] <PlanC> but they have entire dcs at their disposal [18:46:07 CEST] <BtbN> You just do it ONCE [18:46:12 CEST] <kepstin> PlanC: just remux the audio and video files together into a single webm in advance, that's a super fast lossless conversion, and you can delete the original files if you are short on space. [18:46:12 CEST] <PlanC> BtbN, no it actually seeks [18:46:25 CEST] <BtbN> it just fast-forwards until it reaches the desired timestamp. [18:46:27 CEST] <PlanC> but that once applies to so many files [18:46:31 CEST] <BtbN> wouldn't call that seeking. [18:47:07 CEST] <BtbN> Seeking backwards goes back to the beginning, and fast-forwards again [18:47:44 CEST] <PlanC> no I can actually go to different parts of the video [18:47:55 CEST] <PlanC> the only problem is that it sort of lags though [18:47:56 CEST] <Fenrirthviti> It's not actually seeking though. [18:48:05 CEST] <PlanC> I guess that my only is to remux the entire thing [18:48:06 CEST] <BtbN> And I just explained you how it does that... [18:50:05 CEST] <Fenrirthviti> wonder what happens when you try to skip to the part of the file that isn't remuxed yet :P [19:53:03 CEST] <Guest4761> Hi everyone, just to know : If I concat 2 videos, with a different resolution, is it supposed to work ? [19:53:17 CEST] <Guest4761> with the concat demuxer [19:56:10 CEST] <Guest4761> Is the mp4 format OK with different resolutions ? [19:57:05 CEST] <Guest4761> It seems facebook, VLC will play a video with different resolutions, but it will take some time to go from a video to another one [19:57:37 CEST] <DHE> it's not the file format's choice. and generally speaking it's not reliable to change resolution - concat only officially supports nigh-identical encoder settings [19:57:50 CEST] <DHE> even mixing and matching x264 encoder options might not work, for example [20:29:08 CEST] <ac_slater_> alright guys, I have a super weird issue (ffmpeg 3.2). I have an h264 file (annex b) that I mux into mpegts via `ffmpeg -i file.h264 -vcodec copy -f mpegts file.ts` if I strip out the h264 file from the ts file (invert what I did), the md5sums dont match [20:29:26 CEST] <ac_slater_> ie - the mpegts muxer doesnt seem to be invertible :( [20:29:58 CEST] <ac_slater_> it's also adding nal type 9 and sometimes 14 (which are both not really valid for annex b h264) [20:34:47 CEST] <furq> are you sure it's the mpegts muxer and not the h264 muxer [20:37:36 CEST] <BtbN> you should never ever deal with raw .h264 files [20:37:46 CEST] <BtbN> h264 without a container is incomplete [21:12:15 CEST] <ac_slater_> furq: what's an h264 muxer? Basically I expect the h264 file going into the mpegts to be the same thing coming out (if I do -vcodec copy) [21:13:17 CEST] <ac_slater_> BtbN: right, I'm actually writing an interface to an encoder with the libs. But stupidly the encoder spits out huge data so it's actually fed to me as an mpegts stream before I can pipe it to the right place [21:13:35 CEST] <ac_slater_> so h264->mpegts->h264->[what I really want to do with it] [21:13:48 CEST] <BtbN> hm? [21:14:04 CEST] <ac_slater_> but that wont work if I cant retrieve the input nearly untouched from the mpegts mux in the middle [21:14:24 CEST] <ac_slater_> BtbN: that doesnt make sense? Which part? [21:14:57 CEST] <BtbN> You have an application that gives you a raw h264 file? [21:15:13 CEST] <BtbN> and another one that takes it? And in between you use mpegts? [21:16:23 CEST] <ac_slater_> BtbN: yea its super weird. Some device is encoding video into h264. The only thing that device speaks is IP so they pack the encoded h264 into mpegts and send it to me. But I really want the raw bitstream [21:17:12 CEST] <BtbN> why? [21:17:18 CEST] <BtbN> raw bitstream is lacking any timing information [21:17:31 CEST] <ac_slater_> we at least know that ahead of time [21:17:43 CEST] <ac_slater_> rate, etc [21:20:59 CEST] <ac_slater_> I tested this pipeline outside of the streaming thing I just mentioned [21:21:16 CEST] <ac_slater_> I just took an h264 file, muxed it with mpegts, then unmuxed it back to h264 and the md5sums dont match [21:21:19 CEST] <ac_slater_> should they? [21:21:44 CEST] <aptalca> Hi guys, I keep getting "Segmentation fault (core dumped)" whenever I try nvenc or cuvid (or both). I used the johnvansicle build as well as compiled it myself with nvenc and the result is the same. The machine is an ubuntu 16 VM (kvm) with a GT710 passed through. I have nvidia-375 drivers installed as well as cuda 8. FWIW, plex media server, which uses a forked version of ffmpeg can use nvenc with no problems on the same [21:21:44 CEST] <aptalca> machine with the same media so I don't think it's a hardware or an OS problem. Any way I can get more info or logs? Here's the log I have, which doesn't say much: http://sprunge.us/JbZd [21:23:53 CEST] <BtbN> Unless you use the bitexact flags, I wouldn't expect them to [21:24:06 CEST] <BtbN> And even then I'm not sure if all involved components support it [21:24:06 CEST] <DHE> ac_slater_: possibly an annex-B mismatch? [21:24:11 CEST] <ac_slater_> aptalca: try to query your gpus and see "ffmpeg -f lavfi -i testsrc -vcodec h264_nvenc -gpu list -f null -" [21:24:50 CEST] <furq> you should have an ffmpeg_debug binary from when you built it [21:25:02 CEST] <furq> you should probably run that with gdb and get a backtrace [21:25:30 CEST] <ac_slater_> DHE: I'm inserting annexb into the mux and definitely getting annexb out. But I think I found the mismatch. For some reason, when muxing, NAL unit type 9 is added when SPS/PPS occurs [21:25:33 CEST] <aptalca> ac_slater_: that line also gave me a seg fault [21:25:44 CEST] <ac_slater_> aptalca: shux sorry man [21:25:56 CEST] <aptalca> lol [21:26:04 CEST] <ac_slater_> aptalca: I think the nvidia library is trying to dynamically load a shared library you dont have [21:26:40 CEST] <ac_slater_> aptalca: you should have had it in the driver distribution but I'm not sure why. Just rebuild ffmpeg yourself to see if you have the required libs [21:26:53 CEST] <ac_slater_> aptalca: https://developer.nvidia.com/ffmpeg [21:27:01 CEST] <aptalca> ok, I'll try to rebuild again [21:27:24 CEST] <ac_slater_> aptalca: first compile the cuda example for deviceQuery to see if CUDA is working [21:27:30 CEST] <ac_slater_> (and run it) [21:27:35 CEST] <furq> ac_slater_: was that the exact command you ran [21:27:50 CEST] <ac_slater_> furq: for what? [21:27:56 CEST] <furq> i can't even mux .264 into mpegts, it just gives me a pts unset error [21:28:14 CEST] <ac_slater_> furq: do this `ffmpeg -i file.h264 -vcodec copy -f mpegts file.ts` [21:28:31 CEST] <BtbN> you need to add -r 50 or something as input option, so it has a framerate [21:28:32 CEST] <ac_slater_> furq: then `ffmpeg -i file.ts -vcodec copy file2.h264` [21:28:41 CEST] <furq> yeah that doesn't work here [21:28:48 CEST] <furq> doesn't work with -r 30 either [21:28:57 CEST] <ac_slater_> hmm works for me [21:29:02 CEST] <furq> maybe something changed in 3.3 [21:29:04 CEST] <ac_slater_> it's finding the right FPS as well [21:29:08 CEST] <ac_slater_> but maybe I'll force it [21:29:16 CEST] <BtbN> there is no fps to be found in a .h264 file [21:29:20 CEST] <BtbN> it's just a series of raw frames [21:29:23 CEST] <ac_slater_> good point [21:29:27 CEST] <furq> yeah i was curious how your command worked without -r [21:29:31 CEST] <ac_slater_> maybe it defaults to 25 and my source is 25 [21:29:36 CEST] <furq> but it doesn't work at all for me, even with it [21:30:43 CEST] <ac_slater_> hmm maybe -r is broken [21:30:50 CEST] <ac_slater_> cause it's not working when I try to force 30 for example [21:30:53 CEST] <furq> it still works as expected with mp4 [21:30:56 CEST] <ac_slater_> hmm [21:31:19 CEST] <furq> where did you get the h264 es from [21:31:28 CEST] <ac_slater_> I can send you the one I'm using [21:31:33 CEST] <ac_slater_> furq: it's 50 mb [21:31:46 CEST] <ac_slater_> let me make it smaller [21:31:46 CEST] <furq> i'm not really expert enough to diagnose it from that [21:31:52 CEST] <furq> but i got mine from -f lavfi -i testsrc=d=5 [21:31:56 CEST] <ac_slater_> right, I'm just saying it didnt seem to matter [21:32:01 CEST] <ac_slater_> but the testsrc works too [21:32:04 CEST] <BtbN> you have to put -r in front of -i [21:32:07 CEST] <furq> was yours generated by ffmpeg [21:32:09 CEST] <BtbN> otherwise it's an output option. [21:32:17 CEST] <ac_slater_> testsrc + x264 is enough to show that the muxer is not invertible for me [21:32:19 CEST] <furq> that's all i'm wondering about [21:32:33 CEST] <ac_slater_> yea [21:32:37 CEST] <furq> weird [21:33:04 CEST] <ac_slater_> my target is a hardware encoder but even files encoded with x264 resemble the same properties [21:33:21 CEST] <furq> why does it actually matter if it's invertible [21:33:28 CEST] <BtbN> I still don't get why you do that weird dance with raw h264 files. Just transcode the .ts you get? [21:33:34 CEST] <furq> and also yeah that [21:33:49 CEST] <ac_slater_> eh [21:33:54 CEST] <furq> i mean i guess you're going back to 264 to verify it's identical [21:34:00 CEST] <ac_slater_> there are all tiny devices [21:34:09 CEST] <furq> but i don't see why that matters as long as the video streams are identical (-f hash) [21:34:14 CEST] <ac_slater_> the place where the raw streams ends up cant reencoder [21:34:17 CEST] <ac_slater_> reencode * [21:34:33 CEST] <BtbN> this is pure remuxing though, no encoding involved [21:34:38 CEST] <ac_slater_> oh right [21:34:42 CEST] <furq> yeah what does that have to do with the format [21:34:51 CEST] <ac_slater_> BtbN: I think the mpegts muxer is just spitting out a bad h264 file [21:35:01 CEST] <BtbN> I doubt that [21:35:02 CEST] <ac_slater_> "spitting out" when I demux [21:35:09 CEST] <furq> like i said, if -f hash matches up then i don't see the problem [21:35:18 CEST] <ac_slater_> I mean, it does contain nal 0 which is an error [21:35:23 CEST] <ac_slater_> they dont match furq [21:35:35 CEST] <furq> i mean the ffmpeg hash muxer, not just md5sum [21:35:39 CEST] <ac_slater_> ohhh [21:35:43 CEST] <ac_slater_> let me try that [21:36:26 CEST] <furq> that decodes the streams and hashes them, so if those are different then you've got big problems [21:42:20 CEST] <ac_slater_> hmm well [21:42:25 CEST] <ac_slater_> I think you guys are right [21:42:44 CEST] <ac_slater_> but I still think there is a bug somewhere or my input file is just really bad [21:47:13 CEST] <ac_slater_> but doing to mux+unmux with -f hash between everything did yield the same hash [21:47:43 CEST] <ac_slater_> md5sum on the raw files is still a mismatch which is weird [21:47:51 CEST] <ac_slater_> but maybe ok [21:48:11 CEST] <c_14> date header of some type probably [21:48:12 CEST] <furq> the hash muxer hashes the decoded pictures, so if they're packed differently then that makes sense [21:48:21 CEST] <ac_slater_> yea [21:48:31 CEST] <ac_slater_> thanks guys [21:48:32 CEST] <furq> but yeah if you just want to check two streams are identical then that's what you want [21:48:38 CEST] <furq> file hashing is pretty useless at that [21:48:39 CEST] <ac_slater_> so awesome, thanks furq [21:48:56 CEST] <furq> or two streams decode identically, rather [21:48:56 CEST] <ac_slater_> c_14: yea probably [22:02:44 CEST] <ac_slater_> well my final verdict is that the code I wrote against libavformat/codec is weird. I basically just construct a format context against the input, and read AVPackets in a loop appending them to a file. Essentially, I wrote `ffmpeg -i file.ts -vcodec copy file2.h264` [22:02:53 CEST] <ac_slater_> and THAT file is hashing differently [22:02:57 CEST] <ac_slater_> so there is a something [22:05:36 CEST] <ac_slater_> ah ha! [22:05:51 CEST] <ac_slater_> I found which case makes it shit itself [22:08:19 CEST] <ac_slater_> I tried using udp as input to just try to chain these pipelines together with the network as opposed to just trying it on raw files. Raw files always works (hashes are file). But it appears things are SUPER WEIRD over even localhost udp. I'm seeing some loss I think [22:08:24 CEST] <ac_slater_> anyway. thanks guys [22:10:40 CEST] <Bruutal> i have 200,000.00 dollar to invest. what should i invest on? [22:11:16 CEST] <atomnuker> bitcoin [22:12:02 CEST] <ac_slater_> pizza [22:15:03 CEST] <furq> what did you spend the other $50,000 on [22:32:33 CEST] <durandal_170> furq: on sex, drugs and roqnroll [23:15:53 CEST] <Tatsh> finally got a hold on nvenc [23:16:00 CEST] <Tatsh> -qp is the key [23:16:12 CEST] <Tatsh> which is similar but not quite the same as -crf [23:16:22 CEST] <Tatsh> and it's very touchy depending on what resolution you have [23:18:36 CEST] <Tatsh> 480p = 60x speed :) [00:00:00 CEST] --- Thu Jun 1 2017

1 0