Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

December 2017

1 participants
62 discussions

ffmpeg-devel.log.20171205
by burek 06 Dec '17

06 Dec '17

[00:02:48 CET] <philipl> BtbN: so is the submodule idea still on the table? [00:03:36 CET] <philipl> I worry that it's not enough to just have the headers as a bunch of files. Getting a linux distro to package up and include anything is hard enough as it is, and raw headers are not packaging friendly [00:03:49 CET] <philipl> Makefile, pkg-config, versioning, etc, etc. [00:04:37 CET] <wm4> please no submodules [00:12:42 CET] <jamrial> why was this done specifically for nvidia headers anyway? i thought the idea was to move eveything there, including avisynth [00:12:56 CET] <jamrial> so calling the repo codec-headers instead of nv-codec-headers, or whatever [00:16:04 CET] <wm4> isn't that still an open question [00:16:17 CET] <wm4> I'm thinking maybe having specific repos is better [00:16:45 CET] <wm4> to avoid having a repo as literal dumping ground, which would just encourage bad practices such as requiring specific non-standard headers [00:17:01 CET] <wm4> these should be exceptions, not the rule, and having a catch all repo would make it the rule [00:18:19 CET] <jkqxz> There isn't anything else to put in it at all anyway, is there? [00:18:50 CET] <wm4> just nv stuff, and avisynth [00:19:11 CET] <wm4> the AMD headers are obviously already external [00:19:31 CET] <wm4> so yeah I'd argue we should strictly use separate repos for nv and avisynth [00:19:43 CET] <jamrial> but they are not working as is, unless they fixed them during the last few days [00:20:21 CET] <jkqxz> The AMD ones? It got fixed a few days ago. [00:20:33 CET] <jkqxz> At least, I can build an unoptimised build now. Don't know if there are still more problems. [00:20:36 CET] <jkqxz> (Entirely possible.) [00:20:46 CET] <jamrial> ah yes, i see the commit that fixed it now [00:21:37 CET] <wm4> what we definitely should avoid is that we suddenly have to maintain the AMD headers [00:21:49 CET] <wm4> AMD should do that, it's their stuff [00:22:08 CET] <wm4> just like the maintain the drivers backing the headers [00:22:59 CET] <wm4> (and I'd hope nvidia come to their senses and either contribute to the nv header repo, or synchronize their own to it) [00:24:33 CET] <jkqxz> wm4: <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221525.html>. I doubt anyone else will comment on this, shall I just apply it? [00:25:43 CET] <wm4> at least that looks like it should be correct [00:28:37 CET] <jkqxz> Translation: "yes"? [00:29:44 CET] <wm4> yes [00:32:19 CET] <cone-856> ffmpeg 03Mark Thompson 07master:9f7cc87baf2c: rkmpp: Add hardware config information [00:32:20 CET] <cone-856> ffmpeg 03Mark Thompson 07master:c490fc9536dc: vaapi_h264: Add named options for setting profile and level [00:32:21 CET] <cone-856> ffmpeg 03Mark Thompson 07master:71421f382f5c: vaapi_h265: Add named options for setting profile and level [00:39:15 CET] <atomnuker> daddesio: lets start off somewhat simple, the celt encoder lacks postfilter support [00:39:23 CET] <atomnuker> *prefilter [00:40:43 CET] <daddesio> Hmm, is the prefilter specified explicitly in the CELT bitstream? (In LPC, usually the prefilter/postfilter is implicitly calculated based on the LPC filter itself.) [00:47:20 CET] <atomnuker> daddesio: yep, the octave, period, gain and tapset [00:47:34 CET] <atomnuker> the encoder supports encoding those just fine [00:47:51 CET] <atomnuker> and it'll also apply the prefilter just fine [00:47:59 CET] <atomnuker> but the code to do the search isn't there [00:51:19 CET] <daddesio> So if I understand correctly, the CELT prefilter/postfilter isn't (just?) for perceptual weighting (emphasizing/de-emphasizing certain frequencies) but also for emphasizing pure tones, since CELT deals with extremely small MDCT windows and suffers from horrible frequency resolution / energy leakage [00:51:34 CET] <daddesio> hence the name "pitch prefilter" [00:52:22 CET] <atomnuker> yep [00:52:49 CET] <TD-Linux> there is also a preemphasis filter [00:53:01 CET] <daddesio> Oooooh, I was confusing it with that [01:05:56 CET] <atomnuker> jamrial: not seeing any uninit var errors when running valgrind here [01:06:34 CET] <atomnuker> do you know where it happens? [01:09:28 CET] <jamrial> atomnuker: no, just that opus-testvector05 and opus-testvector06 are failing [01:16:29 CET] <atomnuker> does it still happen with the latest git master and the latest fate dir? [01:43:35 CET] <jamrial> atomnuker: yes, just reproduced it on ArchLinux x86_64, configuring with --valgrind=valgrind --disable-optimizations --disable-stripping [01:48:18 CET] <jamrial> atomnuker: also, it might have been ce87e630fa instead [01:49:56 CET] <jamrial> i'll do a bisect [01:58:25 CET] <jamrial> atomnuker: it's fe05f93013 [02:01:06 CET] <atomnuker> which variable is uninitialized? [02:03:36 CET] <jamrial> it complains about sqrtf in celt_stereo_merge [02:04:25 CET] <jamrial> you can't reproduce with the above configure options? [02:54:23 CET] <atomnuker> no [02:54:54 CET] <atomnuker> gcc 7.2 with valgrind 3.13 with args --error-exitcode=1 --malloc-fill=0xa2 --track-origins=yes --leak-check=full [02:55:14 CET] <atomnuker> +that string you pasted in the config file [02:55:23 CET] <atomnuker> *configure script arguments [02:56:43 CET] <jamrial> make sure to run the fate tests lettin makefile add the valgrind args set by configure [02:57:16 CET] <jamrial> but in any case, that's weird. i'm using the same versions [03:02:29 CET] <atomnuker> actually running fate I can replicate [03:04:28 CET] <jamrial> that's why i said the two tests that were failing :p [04:19:39 CET] <atomnuker> erm actually IIR, not FIR, libavcodec/iirfilter.h [04:19:49 CET] <atomnuker> (which is what's used during decoding) [04:28:54 CET] <daddesio> going to update the LPC filter in SILK, too [04:39:45 CET] <daddesio> The LPC filter can be replaced with ff_celp_lp_synthesis_filterf. (or is that API too old and we should use the IIR API instead?) [04:40:36 CET] <daddesio> I see a number of codecs that use ff_celp_lp_synthesis_filterf. [04:41:26 CET] <atomnuker> aren't lpc and iir filters different? [04:42:09 CET] <atomnuker> use whatever you think is more convenient, the iir filter is only used for aac encoder psychoacoustic stuff [04:42:17 CET] <daddesio> An LPC filter is a type of IIR filter, whose b coefficients are: [1]. [04:42:53 CET] <atomnuker> use the celp stuff [04:44:58 CET] <atomnuker> can the lpc filter also be used as a low pass filter? [04:45:27 CET] <atomnuker> the iir filter is really big and used by one thing only, would be nice to get rid of it [04:46:02 CET] <daddesio> I think you can design an all-pole low-pass filter, yeah. [04:46:32 CET] <daddesio> An FIR filter is probably better though (since it's guaranteed to be a stable filter) [04:46:59 CET] <daddesio> and FIR is linear phase etc. [04:47:37 CET] <atomnuker> I really doubt it needs to be perfect, its only used to low pass aac encoder input [04:47:41 CET] <daddesio> and most importantly it can be vectorized (since there's no dependency on the previous output sample) [04:47:55 CET] <atomnuker> yep [04:50:36 CET] <daddesio> where is the low-pass filter you're talking about? [04:52:30 CET] <daddesio> are you talking about celt_apply_preemph_filter? [04:52:36 CET] <atomnuker> its called in ff_psy_preprocess() in libavcodec/psymodel.c [04:52:48 CET] <TD-Linux> the dc rejection in libopus is just 2nd order iir. hard to beat that with a fir. [04:52:49 CET] <daddesio> oh, the psy stuff [04:52:55 CET] <atomnuker> no, this is just for aac [04:53:23 CET] <atomnuker> TD-Linux: good thing we have none of that here then, what a waste [04:53:50 CET] <TD-Linux> oh whoops nevermind, somehow read low pass as dc rejection filter :^) [04:54:08 CET] <atomnuker> it takes less energy to yell at the other person to fix their system than for all opus encoders everywhere to dc reject [04:55:19 CET] <TD-Linux> alright now I don't buy that line of reasoning :) [04:55:48 CET] <atomnuker> how is it even possible to get dc directly on the input? [04:56:05 CET] <atomnuker> and still have a functioning conversation [04:56:16 CET] <TD-Linux> emulators and digital synthesizers can easily produce it by accident [04:57:50 CET] <atomnuker> ought to have their outputs filtered then [04:58:44 CET] <TD-Linux> yes they should, especially because removing dc might cause clipping [04:59:43 CET] <TD-Linux> unfortunately it's rare for them to do it right because normally a sound card would just not reproduce the dc anyway, so it goes unnoticed [05:00:56 CET] <atomnuker> what sucks is that if you want to ac couple an output you need either really big caps or really big transformers [05:04:58 CET] <TD-Linux> yeah. most class ab amps in e.g. laptops go for cap coupled outputs [05:05:17 CET] <TD-Linux> you can omit it for class D amps but they don't work for headphones with a common ground [05:06:57 CET] <atomnuker> the xonar u3 I have seems to go another route I think - limit the current by putting 22 ohm or so resistors in series with the output [05:09:33 CET] <TD-Linux> it could also generate a negative voltage rail and dc couple. some cell phone chips now even have an integrated charge pump to generate the negative voltage [05:11:08 CET] <daddesio> atomnuker: So unfortunately, you can't cleanly rewrite any of the "long term" filters which have a long delay T with the iirfilter.c or celpfilters.c stuff, since they're technically a Tth-order filter with T a/b coefficients. [05:11:32 CET] <daddesio> this includes the CELT pitch filter (celt_postfilter_apply) and the SILK LTP filter. [05:13:17 CET] <daddesio> they're technically Tth-order filters that happen to have a lot of zero coefficients in the middle. [05:15:40 CET] <atomnuker> oh well [05:18:03 CET] <daddesio> The de-emphasis filter is a 2nd-order all-pole filter, so you can technically replace it with ff_celp_lp_synthesis_filterf, but that would make the code a bit confusing (since we're not using it for LPC synthesis). [05:18:44 CET] <daddesio> and it would probably be slower (due to all the arguments you have to pass to the function) [05:19:24 CET] <daddesio> guess I'll just replace the SILK LPC filter for now [05:22:33 CET] <daddesio> Oh but the thing is, the SILK LPC filter clamps each y[n] to +/- 1.0f before writing it out. https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/opus_silk.c#L722 [05:23:01 CET] <daddesio> I wouldn't change it then, since it's an IIR filter we're talking about. [05:23:45 CET] <daddesio> SILK also has a re-whitening filter which does the same thing (clamps each y to +/- 1.0 before writing it). [05:29:21 CET] <atomnuker> so how did x264 end up with that horrid 444 bug in the first place? [07:31:07 CET] <kierank> atomnuker: spec ambiguity if I understand correctly [10:08:13 CET] <RT|AO> @devs: does ffmpeg work in x86 without SSE? [10:09:22 CET] <durandal_1707> yes, there is always pure c implementation [10:12:17 CET] <nevcairiel> i would really not recommend doing that tho =p [10:15:57 CET] <RT|AO> how can I disable SSE in configure? runtime CPU detection seems not working well with my users' CPU. [10:16:55 CET] <durandal_1707> --disable-asm [10:17:13 CET] <BtbN> without sse? [10:17:24 CET] <BtbN> What the hell do you have there, a real 386? [10:17:39 CET] <nevcairiel> runtime cpu detection should be fine [10:17:51 CET] <RT|AO> a vortex86dx [10:17:53 CET] <BtbN> Well, if the CPU really has no sse, I can see that being an issue [10:18:00 CET] <nevcairiel> so basically its not fully x86 compatible? =p [10:18:37 CET] <RT|AO> a i586-compatible x86 CPU targetting embedded use [10:18:49 CET] <RT|AO> s/a /an /; [10:19:10 CET] <thardin> pc/104 eh [10:19:16 CET] <nevcairiel> the only way to disable it entirely is using --disable-asm, but you also lose mmx then, but thats what you have to pay [10:20:47 CET] <RT|AO> OK I'll try that [10:48:32 CET] <durandal_1707> michaelni: did you answered question regarding yuvj formats yesterday? [10:53:19 CET] <BtbN> jamrial, because it can make sense to use older versions of them, to miss out on features, but keep compatible with older drivers. [10:53:51 CET] <BtbN> And because this way it's more packaging-friendly. philipl, I put a makefile and pkg-config file in there. make install and stuff just works. [10:56:01 CET] <durandal_1707> atomnuker: you dissapointed me very much [10:56:59 CET] <atomnuker> durandal_1707: with what? [10:58:34 CET] <durandal_1707> atomnuker: with audio noise removal filter [11:00:17 CET] <atomnuker> believe it or not, last week I worked on it [11:01:34 CET] <atomnuker> I got some of the code ripped out of rnnoise and functional [11:02:15 CET] <atomnuker> not much, but hey, what can I do, av1's going to be frozen "today" [11:02:40 CET] <nevcairiel> didnt they move that to next year [11:03:20 CET] <atomnuker> that's when it'll be frozen solid, now it'll be frozen as in, bugfixes only so no new features [11:03:54 CET] <atomnuker> but I still need to finish the fucking atomics patches so we can finaly declare the unstable period over [11:04:03 CET] <atomnuker> and remove ffserver and make jamrial happy [11:07:45 CET] <cone-381> ffmpeg 03Jim DeLaHunt 07master:d1266d9fa3e8: doc/developer: revise mailing list section [11:12:58 CET] <ubitux> TimothyGu: thx for going ahead with this [11:14:35 CET] <TimothyGu> ubitux: np [11:20:14 CET] <durandal_1707> atomnuker: so what algo it uses? [11:20:57 CET] <atomnuker> neural networks [11:58:02 CET] <RT|Chatzilla> noob question: can ffmpeg be bult with msvc2013? [11:58:41 CET] <BtbN> I'd recommend to use the latest msvc. [11:58:51 CET] <BtbN> 2015 is also mostly fine. But everything before that is a pain. [11:59:05 CET] <wbs> 2013 isn't too bad either, you don't need c99conv [12:01:27 CET] <RT|Chatzilla> BtbN: because my project uses vc2013 [12:01:45 CET] <wm4> I'm sorry [12:07:10 CET] <nevcairiel> i still have a fate box with 2013, but its currently broken, discussion on ML [13:13:00 CET] <durandal_1707> if i do spectral noise subtraction, how should i name the filter? [13:16:56 CET] <atomnuker> durandal_1707: af_doesntwork [13:17:10 CET] <atomnuker> just wait until I got the time to port rnnoise [13:21:00 CET] <durandal_1707> atomnuker: but it works?! [13:23:11 CET] <atomnuker> durandal_1707: I doubt it works well enough to do much [15:30:12 CET] <michaelni> durandal_1707, sorry was too busy to reply yesterday. to awnser, i dont remember but i think it was that people didnt like the yuvj formats. If that changed and people now like to kee them i certainly wont oppose but i think they are a bit ugly, we also dont have a format for 601/709 and the case is similar to the range [15:57:17 CET] <friki> Hi, since yesterday I'm trying to add some features to libavformat/mxf* . I'm searching for MXF specs documents to understand this fileformat. The most complete document I've found is: https://amwa.tv/downloads/specifications/AS-07_Proposed_Application_Specifi… Is it the correct doc? [15:58:29 CET] <JEEB> SMPTE 386M and 377M [15:59:17 CET] <JEEB> 377M is the primary spec I think [15:59:36 CET] <JEEB> then there's additional specs like S429-5 or S429-12 [15:59:41 CET] <JEEB> and S436m [15:59:53 CET] <friki> are them publicaly accessible? [16:00:04 CET] <JEEB> depends, might require googling [16:00:15 CET] <JEEB> granted, check if libmxf already has the feature supported [16:00:29 CET] <JEEB> I kind of wish we could just delegate MXF support to libmxf :) [16:00:38 CET] <JEEB> since they seem to be doing the job nicely enough [16:01:40 CET] <friki> libmxf , i'll take a look! :-) [16:02:27 CET] <JEEB> wow, libmxf still on CVS? [16:02:47 CET] <friki> http://ingex.cvs.sourceforge.net/ingex/ingex/libMXF/ ? [16:03:31 CET] <JEEB> or it's this https://sourceforge.net/p/bmxlib/home/Home/ [16:04:08 CET] <JEEB> yea, it's a git project so sounds much better already :D [16:06:07 CET] <friki> So it make sense to you if I try to put libxml into libavformat/mxf*? "delegate to libxmf" [16:06:58 CET] <thardin> friki: I proposed that a while back [16:07:13 CET] <thardin> it met with quite a bit of resistance [16:08:30 CET] <TimNich> BMXlib is C++ [16:13:17 CET] <thardin> I recall the discussion ending up in something like lavf must have mxfdec on simple principle [16:24:14 CET] <JEEB> TimNich: there's a C one as well if I see correctly [16:24:38 CET] <JEEB> thardin: yet MXF is far from simple :) [16:25:14 CET] <thardin> JEEB: indeed. I'm sure there's plenty of nasty bugs in mxfdec.c [16:25:22 CET] <TimNich> It has a mix of C & C++, istr the C++ is needed for the tiemcode libs [16:25:28 CET] <thardin> and the mxf scene is small enough as it is, that splitting it up over multiple implementations is stupid [16:26:01 CET] <thardin> plus mxf is a purposefully complicated format, for billable hours purposes [16:27:00 CET] <TimNich> ;) [16:29:05 CET] <thardin> or so I've heard! [16:57:24 CET] <BtbN> n [17:22:25 CET] <friki> In my quick preview mxf implementation at libformat isn't ready for "professional usage". I mean lot of TODO: metadata related, data tracks... [19:06:51 CET] <michaelni> durandal_1707, i think you timed-out: <michaelni> durandal_1707, sorry was too busy to reply yesterday. to awnser, i dont remember but i think it was that people didnt like the yuvj formats. If that changed and people now like to kee them i certainly wont oppose but i think they are a bit ugly, we also dont have a format for 601/709 and the case is similar to the range [19:07:41 CET] <durandal_1707> michaelni: where is code that triggers scale filter when pix fmt are different between src and dst? [19:10:55 CET] <durandal_1707> i belive thats main reason why it incorrectly works with fate tests, scale filter is not triggered when it should [19:19:01 CET] <michaelni> durandal_1707, i think libavfilter/avfiltergraph.c but its a while that i touched this [21:25:21 CET] <jrabe> Hi all, first time contributor here. I noticed that ffmpeg eats all of stdin even when converting files (took me a long time to track this issue down). I was wondering if a patch for that is something you're interested in and/or if there's already an open bug for it somewhere. [21:25:44 CET] <BtbN> I don't understand the issue [21:25:50 CET] <BtbN> what else do you expect it to do with the input? [21:26:16 CET] <jrabe> I'm specifying the input file with -i, so ideally nothing at all [21:26:43 CET] <BtbN> ...? [21:26:49 CET] <BtbN> And what is it doing with it? [21:27:22 CET] <jrabe> It's reading all of stdin even though it never uses it [21:27:31 CET] <jrabe> this is what the folks over at #bash sent me: http://mywiki.wooledge.org/BashFAQ/089 [21:28:43 CET] <BtbN> that sounds super weird, why would ffmpeg in that constellation get any input? [21:29:09 CET] <jrabe> I have no idea, that's why it took me forever to figure out it was ffmpeg reading my file list [21:29:26 CET] <jrabe> I had a loop reading multiple filenames and it would always stop after the first iteration [21:29:55 CET] <BtbN> ffmpeg can be controled via keyboard commands, to quit early and some other stuff [21:30:03 CET] <BtbN> so I guess that's what the standard input is used for [21:30:39 CET] <jrabe> I see, that makes sense. No easy fix it looks like then, unfortunately. [21:31:56 CET] <jrabe> Apparently there's a -nostdin flag to disable that. If only I had known before ;) [21:32:04 CET] <jrabe> thanks! [21:34:17 CET] <atomnuker> apparently microsoft added support for opus/vorbis/vp9 in edge using ffmpeg - https://www.neowin.net/news/microsoft-releases-web-media-extensions-package… [21:34:41 CET] <BtbN> And they removed HEVC from Windows [21:37:37 CET] <nevcairiel> no they didnt, they just changed how its updated/installed [21:38:11 CET] <BtbN> Well, you need to install it from the Store now [21:38:18 CET] <BtbN> so it's not a part of Windows anymore [21:38:29 CET] <BtbN> probably got too expensive [21:38:39 CET] <nevcairiel> thats just semantics [21:38:50 CET] <nevcairiel> and i assume there is a license cap which they'll easily hit anyway [21:46:13 CET] <JEEB> nvidia says it goes payware, but so far it's for free @ store [21:46:33 CET] <JEEB> re: the last sentence @ http://nvidia.custhelp.com/app/answers/detail/a_id/4583 [21:46:39 CET] <JEEB> although it could be that they're just clueless [21:48:06 CET] <jrabe> BtbN, now that I think about it, isn't it quite risky for ffmpeg to read stdin by default in non-interactive operations? Imagine you're only processing one file and then running some other commands using data from stdin; ffmpeg could read and silently ignore a bunch of characters until reading a 'q' and quitting, which would change the meaning of the commands run afterwards (e.g. delete the wrong file). [21:48:19 CET] <jrabe> Of course it's not really an ffmpeg issue (ideally shells wouldn't share stdin by default) but I still think -nostdin for -i would be a better default (possibly a breaking change, sadly). [21:54:27 CET] <BtbN> It's not expected to randomly get stuff there, other than control keys [22:06:52 CET] <jrabe> Yeah, I wouldn't really call it a bug since it's actually using stdin, just a small POLA incompatibility, probably. [22:47:14 CET] <gnafu> j-b: You're on the front page of reddit! [22:49:18 CET] <j-b> gnafu: yeah. Sad! [22:49:34 CET] <gnafu> ;-D [00:00:00 CET] --- Wed Dec 6 2017

1 0

ffmpeg.log.20171205
by burek 06 Dec '17

06 Dec '17

[00:00:25 CET] <alexpigment> right [00:00:51 CET] <alexpigment> youtube provides progressive video with square pixels [00:01:01 CET] <alexpigment> and dvd is interlaced video with non-square pixels [00:01:06 CET] <therage3> o.o [00:01:44 CET] <alexpigment> the non-square pixels is why dvd has a resolution of 720x480, but a display resolution of 640x480 (or 853x480 for widescreen) [00:01:56 CET] <alexpigment> somewhere in the chain, that conversion has to happen [00:02:07 CET] <alexpigment> for DVDs, it's the player [00:02:23 CET] <alexpigment> Handbrake just takes that out of the equation so that the player can play the pixels as square [00:02:30 CET] <therage3> for YouTube, it's their encoder and whatever slaps the video on their server [00:02:42 CET] <alexpigment> yeah, and the encoder is just x264 [00:02:47 CET] <therage3> ? [00:02:49 CET] <alexpigment> same as handbrake, ffmpeg [00:02:51 CET] <therage3> how do you know that [00:02:56 CET] <therage3> ???? [00:03:00 CET] <therage3> is that known? [00:03:04 CET] <kepstin> well, they also use libvpx for the vp9 encodes :) [00:03:11 CET] <alexpigment> i don't remember the details, but people around here know this [00:03:12 CET] <therage3> O.O [00:03:20 CET] <therage3> is that uh like [00:03:22 CET] <alexpigment> to be clear, their H.264 encodes are done by x264 [00:03:24 CET] <therage3> something Google revealed? [00:03:38 CET] <alexpigment> again, i don't remember the details. kepstin probably does [00:03:38 CET] <kepstin> therage3: nah, you can figure it out by looking at properties of the encoded video [00:03:49 CET] <therage3> ahh you mean the Stats for Nerds thingie [00:03:52 CET] <therage3> that thing [00:04:22 CET] <kepstin> well, no, that doesn't really say. But if you download the video and analyze the stream, you can figure it out. [00:04:40 CET] <therage3> i see........... [00:04:45 CET] <kepstin> most of what people know about youtube's video encoder, they figured out by uploading test videos then downloading the encoded video [00:05:09 CET] <therage3> Hmmm some interesting shenanigans some people here do :) [00:05:11 CET] <furq> it's known that they're using ffmpeg isn't it [00:05:17 CET] <furq> which narrows the choice down a bit [00:05:21 CET] <kepstin> they use a (fairly old) version of ffmpeg to decode at least some of the input formats [00:05:32 CET] <alexpigment> furq: are you telling me they aren't using the cisco h264 encoder??? ;) [00:05:37 CET] <therage3> O.o [00:05:39 CET] <furq> we may never know [00:06:23 CET] <kepstin> i suspect they aren't using ffmpeg to encode, given how they're known to break the file into segments and do distributed encodes, but there's no real way to tell. [00:06:44 CET] <furq> i assumed they were using something else for vp9 [00:06:51 CET] <alexpigment> i know from 1) watching youtube and 2) having eyes, that they do not prioritize quality [00:06:53 CET] <alexpigment> ;) [00:06:57 CET] <furq> i wasn't aware they were doing distributed encoding for h264 [00:07:06 CET] <furq> but i guess it would make sense for them to do that [00:07:11 CET] <iranen> every youtube video is vp9 and opus by default [00:07:18 CET] <furq> no it's not [00:07:20 CET] <therage3> what [00:07:28 CET] <TD-Linux> it's pretty easy to determine they are just by seeing how long it takes them to encode a long upload. [00:07:35 CET] <therage3> that's not even remotely true, i've used youtube-dl to pull the info [00:07:41 CET] <therage3> and it isn't true that those are the things [00:07:44 CET] <furq> it's h264 and aac by default for new videos until it hits a certain view count [00:07:45 CET] <kepstin> hmm, I thought they were, but again - it's hard to tell. They might be doing a single h264 encode during the upload to have the video immediately ready, maybe? who knows. [00:07:55 CET] <furq> on account of x264 is way faster than libvpx [00:08:03 CET] <alexpigment> yeah, i've never really known the reason for why they have webm videos [00:08:08 CET] <alexpigment> view count makes sense i guess [00:08:17 CET] <furq> that's anecdotal fwiw [00:08:22 CET] <kepstin> they don't do h264 encodes for 4k content, iirc [00:08:22 CET] <therage3> kepstin: it's possible, note that when a video is uploaded, particularly higher quality ones, the low quality ones go up first, followed by the higher resolution ones later [00:08:24 CET] <furq> i am not youtube [00:08:26 CET] <alexpigment> i think all of their 4k stuff is webm [00:08:35 CET] <furq> i think they still do h264? i might be wrong though [00:08:39 CET] <furq> there's definitely h264 at 1440p [00:08:50 CET] <alexpigment> furq: i'm specifically talking about 2160p [00:08:51 CET] <kepstin> they do downscaled copies of 4k videos as h264 [00:08:56 CET] <kepstin> but the 4k itself is vp9 only [00:09:01 CET] <therage3> it's easy to tell. just use youtube-dl on the video with -F flag [00:09:04 CET] <therage3> and see what options it gives [00:09:49 CET] <furq> 266 mp4 3840x2160 DASH video 19296k , avc1.640033, 24fps, video only, 148.41MiB [00:09:55 CET] <furq> also [00:09:58 CET] <furq> 138 mp4 7680x4320 DASH video 65785k , avc1.640033, 24fps, video only, 585.54MiB [00:10:04 CET] <therage3> yah [00:10:14 CET] <TD-Linux> it's dependent on video [00:10:25 CET] <TD-Linux> I don't think they deleted old 4k h264 videos [00:10:30 CET] <TD-Linux> also they change their mind every week [00:10:33 CET] <kepstin> but yeah, from my youtube channel and some other observations, at some point last year it appeared that youtube wasn't doing vp9 encodes until hitting some view count. i haven't checked recently tho. [00:10:35 CET] <therage3> yes. differently uploaded formats and containers get processed differently [00:10:36 CET] <therage3> i think [00:10:41 CET] <furq> 23:10:30 ( TD-Linux) also they change their mind every week [00:10:44 CET] <furq> this much is very true [00:10:47 CET] <therage3> wait, what? [00:10:54 CET] <therage3> until *hitting some view count*? [00:10:57 CET] <therage3> they do that?? [00:11:02 CET] <TD-Linux> I've had a couple of videos that got vp9 basically immediately [00:11:04 CET] <furq> last time i checked my videos, yes [00:11:05 CET] <alexpigment> TD-Linux: that is very true. i've got proof that they changed the encoding of a particular video at least 3 times. seemingly for no reason [00:11:09 CET] <iranen> older videos may be mp4 still on youtube but seen mostly all new videos are vp9 [00:11:10 CET] <kepstin> they appeared to do it as of some time last year when i checked [00:11:15 CET] <furq> all my videos below 150 views had no webm, all above had it [00:11:25 CET] <furq> this was a couple of years ago so it's probably hopelessly outdated now [00:11:30 CET] <furq> they'll have changed policy 18 times since then [00:11:31 CET] <therage3> you have got to be kidding me, that's not even something they're upfront about, is it [00:11:40 CET] <furq> i have actually noticed that recently though [00:11:48 CET] <TD-Linux> it's not really relevant to the end user [00:11:54 CET] <furq> i watch a lot of 2d arcade game superplays which look absolutely shit in h264 [00:12:01 CET] <therage3> ^ [00:12:11 CET] <furq> they always look shit until they hit about 150 views, then they mysteriously look fine [00:12:12 CET] <therage3> some kinds of genres and videos, you can tell [00:12:17 CET] <alexpigment> furq: tbf, that one vlog you did was really good and worthy of webm; the viewcount was secondary [00:12:20 CET] <therage3> so to some end users, it does matter [00:12:21 CET] <kepstin> therage3: IIRC, they always seem to (last I checked) do a minimum of one h264 and one vp8 encode as a baseline for compat. [00:12:27 CET] <therage3> kepstin: i see [00:12:30 CET] <furq> i did a vlog? [00:12:35 CET] <therage3> lol [00:12:35 CET] <alexpigment> furq: i'm joking [00:12:56 CET] <furq> i was really worried for a minute there [00:13:02 CET] <kepstin> and any other encodes you get are bonus, and usually appear later. [00:13:03 CET] <furq> i thought i might have become a youtuber without realising [00:13:09 CET] <furq> hey guys, [00:13:26 CET] <kepstin> don't forget to like and subscribe ;) [00:13:31 CET] <alexpigment> sorry. it seemed like a good joke in my head to insinuate that youtube thought your video was webm-worthy [00:13:46 CET] <furq> you should never joke about something as serious as someone being a vlogger [00:13:47 CET] <alexpigment> i don't understand the rhyme or reason for webm vs mp4 at all tbh [00:14:01 CET] <alexpigment> furq: I'm a habitual line-stepper [00:14:12 CET] <alexpigment> stepping over the line is what I do best [00:14:13 CET] <furq> cocaine's a hell of a drug [00:14:38 CET] <alexpigment> yes, it certainly is, rick [00:14:54 CET] <kepstin> for all we know, whether or not you get a vp9 immediately might be dependent on whether they have spare/unused compute capacity handy. or just an RNG. [00:15:26 CET] <furq> viewcount is my best guess just because every time i've noticed no webm version, it's a low viewcount video [00:15:30 CET] <furq> but that might equally well be age [00:19:37 CET] <oerg866> so we meet again, people of #ffmpeg :D [00:19:46 CET] <oerg866> I'd like to get rid of all of this video noise: https://i.snag.gy/3k0TUC.jpg [00:20:00 CET] <furq> good luck [00:20:12 CET] <oerg866> thanks :P [00:21:01 CET] <oerg866> it's a digitized VHS so theoretically the frequency of the noise exceeds the bandwidth the video had to begin with [00:21:15 CET] <furq> i was about to say that that's more noise than video [00:21:17 CET] <oerg866> so in my naive mind it should be good with like a "low pass filter" on that video [00:21:18 CET] <redrabbit> you need that algo they use in ncis [00:21:23 CET] <alexpigment> this is a capture problem and needs to be dealt with before it gets digitized [00:21:38 CET] <oerg866> no this was recorded off an aerial [00:21:40 CET] <redrabbit> "computer, enhance" [00:21:46 CET] <oerg866> it literally is that bad on the tape [00:22:09 CET] <oerg866> but this is really rare footage so it'd be a shame not to at least give it a whirl [00:22:29 CET] <furq> i mean there might be some denoise filter that is specifically good at this [00:22:41 CET] <furq> any general-purpose one is just going to smear the hell out of it [00:22:50 CET] <oerg866> yeah general purpose is bad because it will do vertical denoising too [00:23:03 CET] <oerg866> but tv signal is line by line so the noise in the lines is independent anyway [00:23:12 CET] <furq> maybe one of the libavfilter gurus will have some ideas [00:23:29 CET] <oerg866> a line based blur which is effectively a low pass filter would be good here i think but again, no experience with the fiilters in ffmpeg :S [00:24:57 CET] <therage3> oerg866: maybe this? https://forum.videohelp.com/threads/352541-Reduce-Video-Noise-With-ffmpeg-c… [00:25:19 CET] <therage3> oerg866: full disclosure, that thread looked promising, but i don't know much about this; ymmv [00:27:49 CET] <alexpigment> oerg866: have you tried another VCR by chance? [00:28:12 CET] <therage3> alexpigment: i just did some testing. apparently if you ask it to keep source framerate, with detelecine filter turned on, it keeps it at 29.97 [00:28:26 CET] <alexpigment> again, i know I seem like I'm harping on this, but as a person who has done a TON of vhs > digital work, it's always best to try two different VCRs, specifically one high end JVC and one high end Panasonic [00:28:30 CET] <therage3> alexpigment: it doesn't reduce it to 23.whatever [00:28:37 CET] <oerg866> alexpigment: It's not the VCR, this was captured off a professional grade machine (panasonic AG-7350) [00:28:45 CET] <alexpigment> therage3: good to know that I had reason to distrust that option :) [00:28:54 CET] <oerg866> and i know the exact reason why this particular episode is so noisy [00:29:09 CET] <alexpigment> ok, just checking [00:29:15 CET] <alexpigment> i'll go back to my corner now ;) [00:29:28 CET] <oerg866> usually the guy who recorded this would record the show off a local station, but when he was out of town he had to catch the rerun on a station that was in another part of the country [00:29:29 CET] <therage3> alexpigment: i used a small chapter from one of the videos to do a quick encode and comparison. now i need to actually extract the frames from both and see wtf the difference is o.O [00:29:38 CET] <therage3> alexpigment: because visually both clips look a priori identical [00:29:44 CET] <furq> alexpigment: i suspect i know the answer to this, but i might as well get confirmation [00:29:48 CET] <furq> https://www.youtube.com/watch?v=bLozqekEnGQ [00:29:49 CET] <therage3> but if they have a different frame rate and have the exact same length [00:29:52 CET] <furq> there's no possible way this came off a vhs, right [00:29:54 CET] <therage3> they must have different frames [00:30:40 CET] <furq> i assume the guy has got the actual source from somewhere but i can't find any evidence of them being leaked anywhere but youtube [00:30:45 CET] <oerg866> <furq> there's no possible way this came off a vhs, right <-- chroma resolution is too high and lack of head switching noise at the bottom [00:30:50 CET] <furq> right [00:31:24 CET] <furq> i notice some delogoing in the top right corner as well [00:32:01 CET] <furq> i actually wonder if this is an hdtv capture from some network rebroadcast [00:32:51 CET] <oerg866> Someone probably got a copy of the master broadcast tape [00:33:00 CET] <oerg866> not sure if stuff was archived digitally in 1995 yet [00:33:04 CET] <furq> it's got to be one or the other yeah [00:33:16 CET] <therage3> wat [00:33:22 CET] <furq> but if the masters had been leaked i'd expect to be able to find it outside of youtube lol [00:33:40 CET] <furq> maybe it's just someone very honest [00:33:40 CET] <therage3> the master broadcast tape? who has access to that other than the network [00:34:03 CET] <oerg866> copies of that get made [00:34:17 CET] <furq> a lot of different networks used the bbc commentary [00:34:24 CET] <furq> so there'll be a bunch of different masters for all of those [00:34:30 CET] <furq> plus any copies that have been made [00:34:44 CET] <therage3> so maybe some "slipped" through the cracks and made its way to YouTube...? [00:34:56 CET] <furq> yeah it's just weird that none of them seem to have made it anywhere else [00:35:13 CET] <furq> the guy's got a bunch of different races in this quality [00:35:24 CET] <oerg866> also networks are "losing" their tapes [00:35:27 CET] Action: therage3 raises an eyebrow [00:35:36 CET] <oerg866> they get rid of their analog archives and give the tapes to employees and stuff [00:35:42 CET] <therage3> i wonder if this guy used to work at one of these channels...... [00:35:46 CET] <therage3> oerg866: interesting [00:37:21 CET] <furq> but yeah there are channels that rebroadcast these races [00:37:28 CET] <furq> and the delogoing makes me wonder if that's where this is from [00:37:35 CET] <therage3> alexpigment: lol so one of the clips has 1913 frames (30fps), the other has 1531 (24fps) [00:37:39 CET] <furq> although that'd be a tiny logo [00:38:46 CET] <therage3> Ahhh interesting [00:38:48 CET] <therage3> I see [00:38:57 CET] <therage3> so the duplicate isn't decimated in the 30fps clip [00:39:01 CET] <therage3> that's where the difference is [00:40:40 CET] Action: therage3 has learned enough about video processing today :D [01:09:49 CET] <rajkosto> hmm if i try to use cuvid via ffmpeg send_packet always returns "no frame!" unless i enable ctx->flags2 |= AV_CODEC_FLAG2_CHUNKS; then it doesnt, but i still never get frames out of receive_frame [01:27:15 CET] <alexpigment> therage3: so did it seem to keep the patterns through the whole video? [01:27:36 CET] <therage3> alexpigment: i have no clue, for some reason ffmpeg's CLI command didn't nuke it all properly [01:27:41 CET] <therage3> yet handbrake worked [01:28:05 CET] <therage3> and i'm not even going to attempt to explain it because that's going down another rabbithole [01:28:25 CET] <alexpigment> therage3: it's possible that ffmpeg's detelecine filter expects the pattern to be the same the whole way through and handbrake's does a rescan of the patterns at certain points [01:28:35 CET] <therage3> yeah, who knows [01:28:44 CET] <therage3> also now i'm terribly confused... for two reasons [01:28:45 CET] <alexpigment> because the most likely place for the pattern to get 'off' is at the commercial breaks [01:29:05 CET] <therage3> get this: https://forums.macrumors.com/threads/handbrake-detelecine-decomb-batman-tas… [01:29:15 CET] <therage3> someone there said "Don't mess with frame rate (leave it same as source)." [01:29:27 CET] <therage3> and here's something else: [01:29:59 CET] <therage3> https://handbrake.fr/docs/en/latest/cli/cli-guide.html [01:30:11 CET] <therage3> go down to the "--detelecine[=string]" parameter [01:30:24 CET] <therage3> "Note: this filter drops duplicate frames to [01:30:24 CET] <therage3> restore the pre-telecine framerate" [01:30:26 CET] <therage3> wat [01:30:39 CET] <therage3> but i looked at, it's still 29.97 [01:30:44 CET] <therage3> what the hell is going on here [01:30:50 CET] <alexpigment> who knows [01:31:11 CET] <alexpigment> the saving grace is that if you're detelecining from NTSC, your target frame rate is always going to be 23.976 [01:31:41 CET] <alexpigment> are you sure you had it on "same as source" for the 30fps one? [01:31:42 CET] <therage3> but if you leave it as source, and it chooses 29.97, what on earth is it using as extra frames? [01:31:56 CET] <alexpigment> extra frames are always duplicates [01:32:04 CET] <therage3> because the detelecine thing according to handbrake's documentation nukes duplicates [01:32:07 CET] <alexpigment> right [01:32:09 CET] <therage3> no, you see, that's the thing [01:32:18 CET] <therage3> the duplicates are supposed to be done [01:32:20 CET] <therage3> gone* [01:32:20 CET] <alexpigment> but then it adds new ones back in if you specify a higher framerate [01:32:26 CET] <therage3> lol wat [01:32:37 CET] <alexpigment> ok, say i have a video that's 15fps [01:32:38 CET] <alexpigment> natively [01:32:43 CET] <therage3> mhm [01:32:45 CET] <alexpigment> and i tell handbrake to output to 30fps [01:32:50 CET] <therage3> sure [01:32:52 CET] <alexpigment> it *creates* duplicates [01:32:59 CET] <therage3> it has to [01:33:08 CET] <therage3> unless you tell it to telecine [01:33:10 CET] <therage3> or whatever [01:33:16 CET] <alexpigment> likewise, if i detelecine to 23.976 and then specify 29.976 output, it creates new duplicate frames [01:33:31 CET] <therage3> yeah, that does make sense [01:33:48 CET] <therage3> here's another wrench thrown into the machinery though... [01:33:57 CET] <alexpigment> now i'm not sure where the problem was - either it was set to "same as source" and failed, or it was set to 29.97 explicitly - but it made up new frames [01:34:28 CET] <alexpigment> either way, i always do both, because i know the desired result, and handbrake can only infer the desired result [01:34:31 CET] <therage3> no, i set it to same as source [01:34:43 CET] <alexpigment> they probably have a bug somewhere [01:34:46 CET] <alexpigment> who knows [01:34:51 CET] <therage3> ._. [01:34:55 CET] <therage3> ok get this [01:34:59 CET] <therage3> from #handbrake 's official channel here [01:35:00 CET] <therage3> https://pastebin.com/raw/ADG1gkaA [01:35:01 CET] <therage3> lol [01:35:04 CET] <therage3> i just asked there [01:35:16 CET] <therage3> this is driving me insane [01:35:36 CET] <alexpigment> haha [01:35:54 CET] <alexpigment> well, don't trust them. if you know it's telecined, just set the framerate to 23.976 [01:35:56 CET] <alexpigment> and call it a day [01:36:01 CET] <therage3> LMAO [01:36:06 CET] <alexpigment> as for decomb, i don't like that option [01:36:15 CET] <therage3> i don't even know what that is, don't care [01:36:27 CET] <therage3> video processing has messed with my head enough for one century :D [01:36:31 CET] <alexpigment> i get why people use it, but it's a filter that's made to achieve passable results for people who don't know what their content is [01:36:41 CET] <therage3> i mean, i can infer it's to get rid of combing artifacts [01:36:46 CET] <therage3> but other than that [01:36:53 CET] <alexpigment> well, here's the deal [01:37:02 CET] <alexpigment> combing artifacts come from one of two scenarios: [01:37:08 CET] <alexpigment> a) the video is telecined [01:37:11 CET] <alexpigment> b) the video is interlaced [01:37:36 CET] <alexpigment> if you know whether your content is telecined or true interlaced, you use either detelecine or deinterlace [01:37:54 CET] <alexpigment> decomb is like "uhh, just get rid of any lines by doing some blurring or line doubling" [01:38:14 CET] <alexpigment> it's never a good replacement [01:38:34 CET] <therage3> omg [01:38:39 CET] <therage3> that's a horrific solution [01:38:44 CET] <alexpigment> now, the person in there that said he also puts it on is right in that there are some cases where the pattern gets weird at transitions, but I treat those on a case by case basis [01:38:54 CET] <therage3> i mean i guess it needs to be done when you have some bizarre mixed interlaced and telecined video [01:38:56 CET] <alexpigment> right [01:39:00 CET] <therage3> and the telecine filter is confused [01:39:28 CET] <jfmcarreira> heyy guys. I am using the following code to read stream using libav: http://dpaste.com/1HAP5PQ. However the function av_read_frame is always returning EOF error [01:40:51 CET] <alexpigment> therage3: still though, i'd rather figure out how to get a properly detelecined video. detelecining gives the best vertical resolution, because you get the full 480 rather than line doubled 240 [01:41:00 CET] <therage3> same here [01:41:31 CET] <therage3> i don't know if this is just how stuff was done back then, but the mastering on this DVD is giving me such a headache [01:42:02 CET] <alexpigment> well, it was probably just taken from the source beta tapes [01:42:06 CET] <alexpigment> or whatever they used back then [01:42:17 CET] <alexpigment> in which case, the telecining was *burned into* the tape [01:42:39 CET] <therage3> so the original source they used was already hard telecined, right into the footage [01:42:45 CET] <therage3> so we're also stuck with it [01:42:46 CET] <alexpigment> i doubt they went back to a film master because they'd have to add credits back in and that sort of thing [01:43:12 CET] <therage3> well, consider that this was a Saturday morning cartoon that only lived two seasons, and was cancelled in 1995 [01:43:15 CET] <alexpigment> well anytime you add video effects on, you're probably already in "video" (telecined) rather than "film" [01:43:24 CET] <therage3> so the original 16/35mm film elements still existing are next to zilch [01:43:26 CET] <alexpigment> what cartoon was it, out of curiosity? [01:43:34 CET] <therage3> Sonic the Hedgehog (commonly known as SatAM) [01:43:39 CET] <alexpigment> there's a company called shout factory that does great re-releases of stuff like that [01:43:44 CET] <alexpigment> ah gotcha [01:43:45 CET] <therage3> ...... that's the company [01:43:45 CET] <therage3> lol [01:43:50 CET] <therage3> Shout! Factory [01:44:10 CET] <jfmcarreira> why am i getting EOF error when calling av_read_frame for the first time? [01:44:14 CET] <alexpigment> well, shout factory generally does good stuff, but they can only do what they can with the masters that are available [01:44:27 CET] <therage3> alexpigment: i see, so this is more DiC/Sega's fault than Shout! Factory's [01:44:54 CET] <alexpigment> on the other hand, they did Pee-Wee's Playhouse by taking the original film and redoing all the effects on top of it. it was a crazy amount of work, but that's why there's a blu-ray available [01:45:00 CET] <alexpigment> you can only do HD if you have the source film [01:45:05 CET] <therage3> exactly [01:45:22 CET] <therage3> and like i said, unfortunately, that source film, the film elements, are more than likely not around anymore [01:45:57 CET] <alexpigment> yeah, they're either gone or hidden in a box somewhere [01:46:33 CET] <therage3> if they're hidden in a box somewhere... i mean, this show does have a huge cult following [01:46:37 CET] <therage3> so, knock on wood [01:46:37 CET] <therage3> :D [01:47:22 CET] <alexpigment> i'm guessing not enough of a cult following to pay for someone to rescan the episodes from film [01:47:35 CET] <alexpigment> and re-do any video-based overlays [01:47:49 CET] <alexpigment> that's a huge amount of money that most companies can't justify [01:47:57 CET] <alexpigment> but they did it with star trek TNG [01:48:32 CET] <alexpigment> and that's really impressive, but they had to recreate so many assets and I think there were some cases where they couldn't find the original scenes so they had to go back to the video masters (SD) [01:48:50 CET] <alexpigment> maybe they finally found them by the end, but the documentary definitely mentioned scenes like that [01:48:52 CET] <therage3> yeah, and... [01:49:14 CET] <therage3> there was also additional drama involving one of the former writers of the now defunct Archie comics for Sonic the Hedgehog [01:49:20 CET] <therage3> that made Sega keep their distance from SatAM [01:49:40 CET] <alexpigment> interesting [01:49:49 CET] <therage3> yeah, it's ... crazy [01:51:01 CET] <therage3> alexpigment https://pastebin.com/raw/P5VwycKy [01:51:03 CET] <therage3> no answer yet [01:51:04 CET] <therage3> lol [01:51:35 CET] <therage3> you know if this is a bug i'm going to their mailing list [01:51:38 CET] <therage3> and reporting it [01:51:48 CET] <alexpigment> well, i can do a quick test to confirm this on my end [01:52:03 CET] <therage3> uh sure, you'll see duplicate frames more than likely but go ahead [01:52:07 CET] <therage3> it'd be useful to compare results [01:53:57 CET] <alexpigment> well, it looks like i'm using a handbrake build from 2013 [01:53:58 CET] <alexpigment> but stil [01:54:00 CET] <alexpigment> *still [01:54:02 CET] <alexpigment> we'll see what happens [01:54:08 CET] <therage3> k [01:54:15 CET] <alexpigment> this is truly a not-broken-don't-fix situation [01:54:36 CET] <alexpigment> (meaning, i'm not downloading a new one because the current one works) [01:55:10 CET] <therage3> sure yeah [01:57:07 CET] <alexpigment> 29.97 [01:58:15 CET] <therage3> mhm [01:58:29 CET] <alexpigment> again, this is an old version, but if yours is new, then that tells me this is at least a 4-year-old bug [01:58:31 CET] <alexpigment> OR [01:58:50 CET] <alexpigment> some developer saw "same as source" and misunderstood it, and changed some code [01:58:57 CET] <alexpigment> because to me, that's confusing as hell [01:59:23 CET] <alexpigment> same as source *would* be 29.97 [01:59:33 CET] <therage3> yeah, especially in light of soft/hard telecine differences [01:59:35 CET] <alexpigment> there needs to be an "auto" option [01:59:47 CET] <therage3> yeah, or "Recommended" [01:59:50 CET] <alexpigment> sure [01:59:59 CET] <alexpigment> something that implies that the frame rate might change due to filters [02:01:30 CET] <alexpigment> same as source also ignores deinterlacing fwiw [02:01:53 CET] <alexpigment> actually, let me do that test again [02:02:00 CET] <alexpigment> i chose "slow" rather than bogb [02:02:01 CET] <alexpigment> *bob [02:02:32 CET] <alexpigment> yeah, same result [02:02:34 CET] <alexpigment> 29.97 [02:03:08 CET] <therage3> i see [02:03:38 CET] <alexpigment> anyway, you can let them know that detelecine and deinterlace both keep the same frame rate as the source, rather than automatically using 23.976 or 59.94, respectively [02:05:12 CET] <furq> i know this is late but i would like to reaffirm that handbrake's decomb filter sucks [02:05:42 CET] <alexpigment> therage3: oh, I just tried something else [02:05:49 CET] <alexpigment> i think you have to set it to variable frame rate [02:05:56 CET] <therage3> alexpigment: lol wat [02:06:02 CET] <therage3> don't most players derp on that [02:06:10 CET] <alexpigment> well, they're using it in a weird way [02:06:15 CET] <furq> is this hybrid interlaced/telecined [02:06:22 CET] <furq> or is handbrake just weird [02:06:28 CET] <therage3> i _think_ it's pure hard telecine [02:06:53 CET] <alexpigment> furq: it seems that when you set it to constant framerate + same as source (frame rate), they honor that very literally [02:06:59 CET] <furq> lol [02:07:10 CET] <furq> i'm not hugely surprised that handbrake is getting stuff horribly wrong [02:07:31 CET] <alexpigment> yeah, i'm not either. it's a good tool for what it is, but it has problems [02:07:48 CET] <furq> you might be better off using ffmpeg [02:07:51 CET] <alexpigment> and a lot of those problems - for me - are that the defaults get in the way of people who know what they're doing [02:08:23 CET] <furq> ivtc is something i've always tried my best to avoid though so idk what combination of filters is recommended these days [02:08:25 CET] <therage3> exactly, right?? [02:08:36 CET] <alexpigment> furq: well, this all started because therage3 has a video that ffmpeg's detelecine filter didn't handle right because the pattern changed. i recommended handbrake because their detelecine is actually pretty reliable in my experience, although i always set the destination frame rate explicitly [02:08:50 CET] <furq> oh [02:08:59 CET] <therage3> yeah, and then it turned out that in their support channel here on freenode, their staff was like "lol no dont do that leave it as source" [02:09:05 CET] <alexpigment> i honestly leave everything as interlaced for the most part, but then again, i deal with a lot of truly interlaced content [02:09:13 CET] <furq> how about the pullup filter [02:09:19 CET] <therage3> the what now? [02:09:27 CET] <furq> there are lots of filters for ivtc in ffmpeg [02:09:28 CET] <alexpigment> pullup is just for soft telecine, right? [02:09:32 CET] <therage3> o.o [02:09:38 CET] <furq> Pulldown reversal (inverse telecine) filter, capable of handling mixed hard-telecine, 24000/1001 fps progressive, and 30000/1001 fps progressive content. [02:09:41 CET] <furq> apparently [02:09:49 CET] <alexpigment> oh nice [02:09:52 CET] <therage3> wait [02:09:53 CET] <therage3> WHAT [02:09:54 CET] <alexpigment> well, i'll have to check that out sometime [02:09:59 CET] <therage3> where the hell was this!!! [02:10:01 CET] <furq> !filter pullup [02:10:01 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#pullup-1 [02:10:21 CET] <furq> i couldn't tell you how good it actually is [02:10:33 CET] <furq> by all accounts people still pull out avisynth/vapoursynth for hybrid interlaced/telecined material [02:11:09 CET] <furq> autodetecting pattern changes is always going to be imperfect [02:12:13 CET] <alexpigment> based on the settings available for this, i wonder how good it is when you don't specify those settings [02:12:22 CET] <therage3> there's no defaults? ._. [02:12:25 CET] <therage3> ugh [02:12:33 CET] <alexpigment> i didn't say there wasn't [02:12:47 CET] <alexpigment> just that you can tell it to ignore pixels on the top, bottom, left and right [02:12:48 CET] <therage3> no like [02:12:55 CET] <therage3> ah [02:12:59 CET] <furq> there's also fieldmatch,decimate [02:13:14 CET] <alexpigment> i think he tried that yesterday with little success, right? [02:13:17 CET] <therage3> i remember someone told me about that [02:13:19 CET] <therage3> in here, even [02:13:22 CET] <therage3> JEEB i think it was [02:13:33 CET] <furq> yeah i seem to remember that's the preferred way now [02:15:06 CET] <therage3> alexpigment: "For best results (without duplicated frames in the output file) it is necessary to change the output frame rate. For example, to inverse telecine NTSC input:" [02:15:09 CET] <therage3> from there [02:15:15 CET] <therage3> that's precisely what you were doing [02:15:21 CET] <therage3> in Handbrake [02:15:22 CET] <alexpigment> yeah [02:15:25 CET] <alexpigment> well, here's the thing [02:15:44 CET] <therage3> alexpigment: also that Bradley guy just got back to me, he said (lol) change to variable framerate and source [02:15:49 CET] <therage3> let's try [02:15:53 CET] <alexpigment> if there's a filter that's decimating based on similarity between frames, i don't want that to cause the frame rate to change when nothing is going on (e.g. black frames) [02:16:07 CET] <alexpigment> so i set the frame rate explicitly [02:16:29 CET] <alexpigment> but i think with the pullup thing, it's saying that because your output will be VFR for truly mixed content [02:16:44 CET] <therage3> yeah i see [02:17:00 CET] <alexpigment> i personally would just leave that stuff as interlaced [02:17:10 CET] <alexpigment> or perhaps go to 59.94 if i needed progressive [02:17:29 CET] <alexpigment> either way, there's a million ways to do all this, sadly [02:17:42 CET] <therage3> so i see ._. [02:18:12 CET] <alexpigment> so i just usually avoid the hassle, leave it as interlaced, and make sure to use a player that knows how to deinterlace properly (e.g. Kodi, Windows Media Player) [02:18:30 CET] <alexpigment> and I sit back and let the smooth frames lull me into a satisfied stuper [02:18:38 CET] <therage3> in any case, i guess this variable frame rate thing may work [02:18:41 CET] <therage3> let's see what it does [02:18:43 CET] <alexpigment> yep [02:18:54 CET] <alexpigment> it worked on my end - at least for deinterlace [02:19:00 CET] <alexpigment> but the frame rate was a tiny bit off the spec [02:19:20 CET] <alexpigment> 59.907 instead of 59.97 [02:19:24 CET] <therage3> o.o [02:19:30 CET] <alexpigment> that's actually not uncommon [02:19:36 CET] <furq> yeah if it is a straight detelecine it'll be cfr output [02:19:40 CET] <furq> so maybe bradley just sucks [02:19:40 CET] <alexpigment> sometimes it's the container that does it [02:19:50 CET] <alexpigment> haha [02:19:55 CET] <alexpigment> good ol' bradley [02:20:14 CET] <therage3> hahahahahaha [02:20:35 CET] <therage3> well, i guess the variable option covers all your bases [02:20:50 CET] <therage3> if it's a standard patterned hard telecine, it'll theoretically come out cfr [02:21:16 CET] <alexpigment> try a test (preview) of like 30 seconds or so and see if it actually comes out at 23.976 [02:21:33 CET] <therage3> yeah, i use this 1:04 intro theme from the show to test it out [02:21:34 CET] <alexpigment> it could be slightly off, depending on if they're doing some additional decimating [02:22:10 CET] <therage3> i cannot believe how much i learned today o.o [02:23:20 CET] <alexpigment> in no time, you'll be talking to your friends and loved ones about how you defeated this hard telecined video, and they will absolutely love hearing about it ;) [02:23:48 CET] <therage3> ok, what the .... [02:23:59 CET] <therage3> what spec is effing 24.54 fps now?? [02:24:03 CET] <alexpigment> working with video on a deep level is a lonely hobby or job. no one understand what the hell you're talking about [02:24:03 CET] <therage3> is this thing trolling me? [02:24:09 CET] <therage3> that's closer to the PAL broadcast standard [02:24:10 CET] <alexpigment> therage3: that's what I figured [02:24:16 CET] <alexpigment> it's not perfect [02:24:23 CET] <therage3> this thing has to be trolling me [02:24:24 CET] <therage3> holy hell [02:24:26 CET] <alexpigment> set it to 23.976 and call it a day [02:24:40 CET] <alexpigment> tell bradley to suck it as well ;) [02:24:40 CET] <furq> if you cropped a portion out then that could maybe be one extra frame [02:24:49 CET] <furq> depending on how the tool you're using is calculating the framerate [02:24:58 CET] <therage3> it's VLC [02:25:05 CET] <therage3> i dunno how VLC does it [02:25:12 CET] <furq> i wouldn't trust vlc to tell me what a traffic cone looks like [02:25:17 CET] <therage3> LMAO [02:25:19 CET] <alexpigment> haha [02:25:25 CET] <therage3> ok hold on then [02:25:25 CET] <furq> ask ffprobe [02:25:26 CET] <alexpigment> usually *i'm* the one bashing vlc in here [02:25:28 CET] <therage3> let me ffprobeit [02:25:50 CET] <alexpigment> and offending vlc developers who are trying to defend the shortcomings of the software [02:25:59 CET] <therage3> Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, smpte170m/smpte170m/bt709), 720x480 [SAR 8:9 DAR 4:3], 3371 kb/s, 24.54 fps, 120 tbr, 90k tbn, 180k tbc (default) [02:26:01 CET] <therage3> same [02:26:07 CET] <furq> neat [02:26:12 CET] <therage3> VLC is surprise surprise, correct here [02:26:12 CET] <therage3> lol [02:26:21 CET] <furq> i mean it is right sometimes [02:26:24 CET] <furq> but i'd always get a second opinion [02:26:31 CET] <alexpigment> agreed [02:27:14 CET] <alexpigment> admittedly, one of the advantages of vlc is that it kinda ignores a lot of metadata and brute forces what it knows about a video. for videos that aren't made correctly, this can sometimes mean it's the only play that plays the video [02:27:44 CET] <alexpigment> *player [02:27:52 CET] <therage3> yeah, i've had a bunch of players tell me a video is corrupt and refuse to play it [02:28:06 CET] <therage3> VLC plays it, but when it gets to the corrupt section, acts up briefly, but resumes after it passes [02:28:11 CET] <furq> where did you get that clip from btw [02:28:13 CET] <furq> is that from handbrake [02:28:27 CET] <therage3> the one i ran through ffprobe? yeah [02:28:31 CET] <furq> fun [02:28:32 CET] <therage3> the source is a DVD [02:28:46 CET] <alexpigment> he detelecined with setting the frame rate to "variable" while on same as source [02:28:53 CET] <therage3> ^ [02:28:59 CET] <furq> yeah that just sounds like their detelecine filter isn't very good [02:28:59 CET] <therage3> that's the origin of the variable frame rate [02:29:09 CET] <therage3> aaaaand now i'm ocd again [02:29:15 CET] <therage3> o.o [02:29:21 CET] <furq> maybe it's trying to do some smart detelecining and leaving some dup frames in [02:29:22 CET] <alexpigment> furq: but honestly, it works pretty well, as long as you set a CFR [02:29:54 CET] <alexpigment> i think it does something intelligent, which is why I tend to use it over ffmpeg for this particular scenario [02:30:21 CET] <alexpigment> it also drops dupe frames pretty intelligently, which comes in handy when I have a 60p source that was originally 24fps [02:30:27 CET] <therage3> the question is, if you set their detelecine filter to "Default" settings and force 23.976 fps, will there ever be a loss of any frame? like an original progressive frame, gone [02:30:31 CET] <furq> lol [02:30:34 CET] <furq> apparently it's using -vf pullup [02:30:42 CET] <alexpigment> well, there you go :) [02:30:46 CET] <alexpigment> maybe i should start using pullup [02:31:03 CET] <furq> looks like its own implementation of it though [02:31:08 CET] <therage3> oh [02:31:10 CET] <therage3> so not ffmpeg's_ [02:31:11 CET] <therage3> ? [02:31:40 CET] <furq> https://github.com/HandBrake/HandBrake/blob/master/libhb/detelecine.c [02:31:48 CET] <alexpigment> given that handbrake is highly invested in the DVD ripping scene, they probably put some extra TLC into that filter [02:32:20 CET] <furq> does the clip have any duplicate frames left [02:32:39 CET] <furq> if it doesn't then i would guess it is actually doing the right thing and you don't have a fixed telecine pattern [02:32:49 CET] <furq> which is extremely common for cartoon intros and stuff [02:32:59 CET] <therage3> LOL [02:33:04 CET] <therage3> that is EXACTLY what i have here [02:33:08 CET] <therage3> the intro to a cartoon [02:33:11 CET] <furq> enjoy skipping through 1350 frames [02:33:12 CET] <therage3> that explains it [02:33:13 CET] <furq> and yeah i read up [02:33:31 CET] <alexpigment> the intros in particular (and outros) i wouldn't trust to be true telecined tbh [02:33:32 CET] <therage3> well, that's the thing, i actually need to look at the original to see if _that_ has any duplicates [02:33:52 CET] <alexpigment> just because they might doing the credits in video on top of the telecined footage [02:34:07 CET] <alexpigment> in which case, i'd still just force it to 23.976 [02:34:26 CET] <therage3> the intro doesn't have credits, and fortunately the outro is just a still image with text changing [02:34:28 CET] <alexpigment> or again, leave it as interlaced if there's some visual value to having smooth animations on the credits [02:35:51 CET] <alexpigment> therage3: the source will inherently have duplicates though, right? [02:36:04 CET] <alexpigment> you mentioned looking at the source [02:36:14 CET] <alexpigment> or rather, the "original" [02:36:21 CET] <therage3> right, the DVD source [02:36:38 CET] <alexpigment> yeah, it's telecined, so you're going to see that pattern of dupe frames [02:36:38 CET] <therage3> and then one has to wonder how their filter decided to deal with those [02:36:55 CET] <therage3> no i mean [02:36:59 CET] <therage3> outside of the pattern [02:37:06 CET] <alexpigment> oh i see [02:37:09 CET] <therage3> something that's part of the _animation_ intendedby the animators [02:37:20 CET] <therage3> like something that's still [02:37:23 CET] <alexpigment> yeah that can be hard to tell [02:37:37 CET] <therage3> yeah, and who is going to tell the filter ._. [02:37:38 CET] <therage3> lol [02:37:40 CET] <alexpigment> i just try to find a long panning scene [02:37:47 CET] <therage3> it'll just go DECIMATE AAAAAAAAAHHHHHHH [02:37:49 CET] <therage3> lol [02:37:56 CET] <alexpigment> well, filters are surprisingly good about seeing the differences in frames that humans aren't [02:38:02 CET] <therage3> o.o [02:38:04 CET] <alexpigment> because in analog sources, there will be a difference in grain [02:38:12 CET] <therage3> right [02:38:45 CET] <alexpigment> you have to sort of turn your brain off and look for differences in grain rather than differences in the construction of the frame [02:39:16 CET] <therage3> i see [02:40:24 CET] <therage3> k so [02:40:42 CET] <therage3> i dunno if i'm doing something wrong but i took that new vfr clip and extracted all its frames [02:40:58 CET] <therage3> there's ~ 8000 frames.... [02:41:01 CET] <therage3> versus 1350 [02:41:09 CET] <therage3> uhm ok, am i like tripping? [02:41:21 CET] <alexpigment> how many fingers am i holding up? [02:41:26 CET] <therage3> lol [02:42:04 CET] <alexpigment> i don't know man. i think bradley sort of confirmed that he doesn't know how it really works, and i think that kinda points to the fact that it doesn't really work like it's supposed to with VFR [02:42:24 CET] <therage3> wow [02:42:27 CET] <therage3> i just looked at the frame [02:42:29 CET] <therage3> s [02:42:35 CET] <therage3> there's a TON of duplicates [02:42:41 CET] <alexpigment> last time i'll say it: set the frame rate to what you think it should be [02:42:49 CET] <therage3> yes yes gotcha [02:42:49 CET] <furq> if it's vfr then ffmpeg won't be extracting it properly [02:42:51 CET] <alexpigment> and make sure it doesn't have any dupes afterward [02:42:55 CET] <therage3> furq: oh [02:43:01 CET] <furq> you need to do like -vsync 0 or something [02:43:05 CET] <furq> i forget exactly what now [02:43:15 CET] <alexpigment> oh crap, the vsync [02:43:15 CET] <furq> it definitely shouldn't have given 8k output frames though [02:43:22 CET] <therage3> ikr? [02:43:27 CET] <therage3> that's why i asked, am i tripping? [02:43:28 CET] <alexpigment> we're getting deep here, and I need to start making dinner [02:43:32 CET] <furq> but yeah you should be able to framestep in your player [02:43:34 CET] <therage3> because with the average frame rate [02:43:36 CET] <therage3> and the length [02:43:38 CET] <therage3> that did not add up [02:43:40 CET] <therage3> the math did not work. [02:43:41 CET] <furq> i think it's like space in vlc or something unintuitive [02:43:49 CET] <therage3> oh jeez [02:43:51 CET] <alexpigment> i use videoredo for framestepping fwiw [02:43:55 CET] <furq> i just use mpv [02:44:02 CET] <alexpigment> it's a paid program, but completely worth every single penny for what it does [02:44:11 CET] <alexpigment> anyway, i'm off to make dinner [02:44:12 CET] <alexpigment> later guys [02:44:17 CET] <therage3> alexpigment: thanks for the help, enjoy [02:47:01 CET] <therage3> yeah, sure enough, with VLC frame stepping shows next to no duplicates [02:49:04 CET] <therage3> https://mattgadient.com/2013/06/12/a-best-settings-guide-for-handbrake-0-9-… [02:49:05 CET] <therage3> hmmm [02:49:09 CET] <therage3> this guide also suggests variable [02:50:08 CET] <furq> vfr is only useful for ivtc if it's not a consistent telecine [02:50:18 CET] <furq> if you know for a fact that you have one then you should use cfr [02:50:28 CET] <furq> but you'd need to framestep the entire source clip to be sure of that [02:50:59 CET] <therage3> LOL [02:51:08 CET] <furq> also i suspect you wouldn't be having this much difficulty if it was a clean telecine [02:51:11 CET] <therage3> the intro alone is ~ 1350 frames [02:51:24 CET] <therage3> furq: exactly [02:51:29 CET] <furq> pattern changes and 30i scenes/overlays are the bane of IVTCing [02:51:41 CET] <furq> and either of those usually means you're stuck with vfr output [02:51:58 CET] <therage3> or also, maybe because the source material was poorly transferred from the broadcast masters to DVD, the filter is having a hard time [02:52:04 CET] <therage3> even if the telecine is constant [02:52:09 CET] <furq> and also dvds weren't mastered with this in mind so they're all made by idiots who hate you [02:52:16 CET] <therage3> right, exactly [02:52:51 CET] <furq> well -vf detelecine should've worked fine in that case because that doesn't try to do anything clever [02:53:01 CET] <therage3> hm, that's also true o.O [02:53:01 CET] <furq> it just combs and drops at a fixed interval [02:53:15 CET] <therage3> i guess the telecine is variable then [02:53:49 CET] <furq> that is often also caused by bad transfers [02:54:48 CET] <therage3> yeah, like i said [02:57:24 CET] <therage3> i do wish this show eventually gets released in HD [03:33:27 CET] <zyme> Is there a specific name for those visible artifacts that are not noise - the ones that are visible line shapes that don't move that can be seen in solid colors (I'm not talking about color gradients/banding either)? [03:33:45 CET] <DHE> like the stuff you see in jpegs? [03:35:11 CET] <zyme> looks similar. its like in lower bitrate x264 or HEVC, but arn't blocking artifacts either. [03:35:48 CET] <DHE> yeah h264 tends to smudge the image more than older mpegs which tended to block up more [03:41:06 CET] <zyme> there's still more blocking artifacts even in HEVC than I would expect, especially if you kind of get your eyes to stay looking still and unfocus a bit so your attention is not on the movement - its easiest if you get up real close but from a distance you almost don't notice them without getting use to looking for it. [03:42:28 CET] <zyme> whats the new replacement for HEVC called again - I want to say JET, but even if thats right I don't know if that'll be the offical name or if its just the dev projects name.. [03:42:47 CET] <TD-Linux> they are from intra prediction [03:42:58 CET] <TD-Linux> JEM is the software you're thinking of [03:44:26 CET] <zyme> thats it [03:46:02 CET] <zyme> so is JEM going to be its name like HEVC or is it just the dev project's name? (lol) [03:46:07 CET] <TD-Linux> h.266 [03:47:28 CET] <furq> zyme: ringing? [03:48:47 CET] <zyme> furq: the artifacts? a lot of it does look like curved lines like parts of rings and some circular lines sometimes [05:05:51 CET] <dr0pkick> I am trying to build ffmpeg from source on CentOS 7, everything works except a ffplay binary isn't getting generated. [05:07:44 CET] <furq> ffplay depends on sdl2 [05:08:18 CET] <dr0pkick> I added that dependency, I read that it was quietly causing it to not build. Still isn't being generated though. [05:08:26 CET] <furq> ffplay is also not particularly good [05:08:33 CET] <furq> it's only really useful for debugging [05:08:43 CET] <tdr> isnt it one of the ones you have to cd into and run make manually for? [05:08:47 CET] <furq> no [05:08:55 CET] <furq> at least not last time i checked [05:09:03 CET] <tdr> lemme check my source [05:11:05 CET] <tdr> nope [08:21:36 CET] <illegal> https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio [08:21:46 CET] <illegal> " When compatibility with hardware players doesn't matter then use libvorbis in a MKV container when libfdk_aac isn't available. " [08:21:48 CET] <illegal> Why? [09:17:33 CET] <mistym> Is there a way to access individual frames from an AVStream during *_write_header in a libavformat muxer? [09:18:47 CET] <mistym> I'm writing a new muxer for a format which has an up-front sample table in the header. [12:11:48 CET] <Nacht> I think that Windows 10 bash is breaking something in ffmpeg/ffprobe when you try to grab something from an url [12:11:53 CET] <Nacht> Segmentation fault (core dumped) [14:27:29 CET] <Bear10> does anyone know how to restream from one rtmp to another without losing quality, for whatever reason when i do ffplay and look at my rtmp stream it's perfect, when i send it to facebook it's horrible, even when my rtmp goes to my own hls server the quality is still good [14:28:49 CET] <Bear10> i thought ffmpeg -i rtmp://.... -c:v copy -c:a copy -f flv rtmp://.... would do it [14:28:49 CET] <BtbN> don't transcode it [14:28:56 CET] <BtbN> Just -c copy is enough [14:29:29 CET] <Bear10> hmm ok ill give it a shot see if it improves anything [14:30:13 CET] <BtbN> It's the same, just less stuff [14:30:57 CET] <Rajko> Bear10, you havent thought that facebook is recompressing for you ? [14:31:47 CET] <Bear10> Rajko: could be, but i figured that if i went from OBS -> FB and it was good quality, and i went from OBS -> my platform -> FB it'd be the same result [14:32:13 CET] <BtbN> It is. With -c copy it will forward the exact same bitstream. It has no impact on the quality. [14:34:50 CET] <Bear10> ok well as long as the commands good maybe its my environment [14:34:54 CET] <Bear10> ill test with bigger servers eventually [14:38:39 CET] <dradakovic_> Has anyone here successfully streamed into dvbt from ffmpeg using mpegts? I am streaming a radio but it is causing me issues. I believe the UDP packets flow too fast [14:40:30 CET] <JEEB> see the UDP protocol options and the mpegts muxer options [14:40:40 CET] <DHE> I am streaming from ffmpeg straight into a cable plant, yes [14:40:52 CET] <JEEB> UDP has -bitrate and MPEG-TS has -muxrate [14:40:53 CET] <JEEB> IIRC [14:41:08 CET] <DHE> hang on didn't I already answer this yesterday? [14:41:24 CET] <dradakovic_> Not to me you didnt lol [14:41:54 CET] <DHE> <dradakovic_> so input is http, converting it to mp3 and streaming it to mpegts // could've fooled me [14:42:28 CET] <dradakovic_> Ok but the question was different wasn't it [14:44:07 CET] <DHE> $ ffmpeg -i [input] [codec-options] -f mpegts -muxrate 300k -bitrate 310k -pkt_size 1316 udp://239.255.255.7:23456 # a good starting point for a 256 kilobit mp3 stream [14:44:08 CET] <dradakovic_> DHE, would you mind sharing your command here [14:44:14 CET] <dradakovic_> thank you [14:44:41 CET] <DHE> and do make sure you're on a recent ffmpeg. old distro versions may reject the bitrate option because they're old [14:45:43 CET] <dradakovic_> Ok. I compiled the newest [15:02:57 CET] <dradakovic_> I use this command which is probably similar to yours. But it is cutting when listening on our dvb equipment. [15:02:59 CET] <dradakovic_> https://pastebin.com/V5Kv4PrN [15:04:12 CET] <dradakovic_> We are ISP and when i compare ffmpeg radio with our enterprise radios, i can see that many more UDP packages get sent in the same period of time. [15:04:50 CET] <dradakovic_> I also can't seem to find a good option for -muxrate as the radio simply works worse with any of my entries [15:05:40 CET] <zyme> "kovic", that means "son of", so son of Drada? [15:06:47 CET] <dradakovic_> Honestly, this is how my company named my laptop and hexchat took it as my nickname. Radakovic is my last name [15:07:07 CET] <zyme> My last name is Yaskovic [15:07:21 CET] <zyme> Translates to son of Joseph [15:07:21 CET] <dradakovic_> Russian? [15:07:29 CET] <zyme> Austria-Hungry [15:08:07 CET] <dradakovic_> Cool. Now i know more about my name. [15:09:06 CET] <JEEB> O [15:09:28 CET] <JEEB> I've also had issues with different gear taking in UDP multicast from lavf, where I seemingly set muxrate and udp's bit rate [15:09:43 CET] <JEEB> but I've never gotten a chance to poke at the gear that was having issues again [15:09:44 CET] <zyme> Y's and J's looked similar in script so for some reasons a lot of J's became Y's when my family immegrated to NY. [15:09:51 CET] <JEEB> to see how it could be debugged [15:11:29 CET] <DHE> JEEB: the secret is to make sure you set the pkt_size to a multiple of 188 (1316 is a favourite since it maxes out as close to the 1500 MTU as possible) and use the bitrate option for UDP [15:11:30 CET] <dradakovic_> if i set my muxrate the same as my bitrate i keep getting dts < pcr. TS is invalid. And radio plays slower [15:11:56 CET] <DHE> modern ethernet switches are garbage and have tiny packet buffers. the pacing is more to prevent networking gear from dropping packets than the endpoint's limitations [15:11:58 CET] <zyme> some of the older family members pronounced the Y with an accent closer to a J, lol. lots of weird spelling changes happened at ellis island back in the days. [15:12:21 CET] <DHE> dradakovic: as I said, mpegts has overhead - at least 10%. that's why I suggested 300 kilobits for a 256k CBR stream [15:12:32 CET] <DHE> a bit overkill, but better safe than sorry [15:12:36 CET] <DHE> and 300 is a nice number. :) [15:13:12 CET] <JEEB> DHE: yea I think that was set as well [15:13:18 CET] <JEEB> @ pkt_size [15:13:28 CET] <JEEB> but as I said, I've not been in the room with the equipment since :D [15:13:54 CET] <DHE> JEEB: I recommend confirming with wireshark if possible. as well as dissecting the packets to see they're intact, check the time between packets to make sure it's consistent. typically a good 1/2 millisecond at least [15:14:02 CET] <JEEB> yea [15:14:21 CET] <JEEB> also one idea we had was to just restream another multicast from the same box [15:14:39 CET] <dradakovic_> What if the timing is not the same. I suspect i have that issue [15:14:42 CET] <JEEB> to first of all make sure that the box could provide a multicast that things accept [15:15:42 CET] <DHE> it means the bitrate isn't being set correctly or your system doesn't support it (you should get an alarm though, right?) [16:51:08 CET] <ahjolinna> hello, I tried to compile ffmpeg-full-git on arch (testing) but it currently fails to build (stable 3.4.x builds fine), build log: https://pastebin.com/raw/MjtsT4fh [16:57:05 CET] <durandal_1707> ahjolinna: update zimg lib [16:58:45 CET] <ahjolinna> I did update zimg to latest 2.6.3 [17:00:18 CET] <ahjolinna> (arch is still using 2.6.2, which should be the minimum version req.) [17:10:02 CET] <durandal_1707> ahjolinna: i guess then you need zimg master [17:11:02 CET] <ahjolinna> I could try it, but according to this 2.6.2 is the minimum version req. https://github.com/FFmpeg/FFmpeg/commit/002db7d49ada290db15334b7b41fa27eb37… [17:11:54 CET] <durandal_1707> either commit is wrong or configure picks up wrong headers [17:15:32 CET] <ahjolinna> okay that worked [17:55:54 CET] <SortaCore> so, tune, profile, level, preset, avg/max bitrates [17:56:03 CET] <SortaCore> which of these are used together and which can't be? [17:56:13 CET] <alexpigment> all of them can be used together [17:56:28 CET] <SortaCore> really? [17:56:45 CET] <alexpigment> some of the very specifics may be overlapped and/or stomped on by other settings [17:56:48 CET] <alexpigment> but generally speaking, you can use them all [17:56:52 CET] <c_14> (with libx264 anyway) [17:57:00 CET] <alexpigment> and frequently I use all of those [17:57:26 CET] <alexpigment> if you actually want to stay within a strict set of specs, you kinda need to use most of them [17:57:47 CET] <alexpigment> e.g. blu-ray [17:57:59 CET] <therage3> all right [17:58:02 CET] <therage3> time to learn some more video processing [17:58:06 CET] Action: therage3 stretches [17:58:17 CET] <alexpigment> :) [17:58:56 CET] <alexpigment> SortaCore: do you have a particular underlying question that relates to this, or was it just a curiosity? [18:06:35 CET] <dakar> hello guys [18:06:46 CET] <therage3> hey [18:06:50 CET] <dakar> i want to join some 10 .mov files in order to reencode them with handbrake afterwards [18:07:09 CET] <dakar> so basically just join them with minimal processing to make it fast. handbrake will do the work later [18:07:15 CET] <alexpigment> https://trac.ffmpeg.org/wiki/Concatenate [18:07:17 CET] <dakar> i tried to follow the manual, but no luck [18:07:31 CET] <alexpigment> are the videos in the same format? [18:07:42 CET] <alexpigment> e.g. same codecs, same settings, etc? [18:07:42 CET] <dakar> should be same-everything. they were recorded with the same device one after the other [18:08:00 CET] <alexpigment> ok [18:08:00 CET] <therage3> dakar: https://stackoverflow.com/questions/15908328/ffmpeg-to-combine-two-mov-file… [18:08:01 CET] <alexpigment> you can use the concat demuxer [18:08:02 CET] <therage3> replace two with ten, and that should work I guess [18:08:04 CET] <dakar> i tried this: ffmpeg.exe -i concat:"17540002.MOV|17540003.MOV" -c copy 2p3.mov [18:08:15 CET] <dakar> but the output file ended up being merely the 17540002.MOV [18:08:45 CET] <dakar> i took the syntax from here https://ffmpeg.org/faq.html#How-can-I-join-video-files_003f [18:08:58 CET] <alexpigment> yeah, it's probably because you are using MOV files [18:09:32 CET] <dakar> i am. [18:09:40 CET] <dakar> i dont want to mess with their encodings though, so handbrake could handle it later on [18:09:52 CET] <dakar> (i'm not very familiar with it to pick the right settings in cli) [18:10:03 CET] <alexpigment> well, it's worth noting that handbrake uses x264, which ffmpeg uses too [18:10:24 CET] <therage3> dakar: i see [18:10:24 CET] <alexpigment> but either way, you can first convert your files to mpegts [18:10:24 CET] <dakar> like i said, im not familiar with the settings [18:10:42 CET] <dakar> mpegts means the sources arent touched quality-wise? [18:10:43 CET] <alexpigment> ffmpeg -i [infile] -c copy output.ts [18:10:56 CET] <alexpigment> the -c copy means that it won't be touched quality-wise [18:11:09 CET] <alexpigment> now i'll be the first to tell you that the mpegts muxer in ffmpeg sucks [18:11:24 CET] <alexpigment> and so the audio will fail to be included in some cases, depending on the format of the source [18:11:29 CET] <alexpigment> so you'll need to test this [18:11:37 CET] <dakar> [mpegts @ 022b7020] H.264 bitstream malformed, no startcode found, use the h264_mp4toannexb bitstream filter (-bsf h264_mp4toannexb) [18:11:52 CET] <alexpigment> ok, so add that last command in [18:12:02 CET] <alexpigment> -bsf h264_mp4toannexb [18:12:09 CET] <therage3> dakar: did you see my link before? [18:12:17 CET] <therage3> dakar: it literally had that command in it that ffmpeg wants [18:12:19 CET] <dakar> therage3 sorry, no. the stackoverflow? [18:12:28 CET] Action: therage3 blinks [18:12:59 CET] <therage3> ffmpeg -i input1.mp4 -c copy -bsf:v h264_mp4toannexb -f mpegts intermediate1.ts <<< this is the first command from the accepted answer [18:13:06 CET] <therage3> it has everything in it that you need i guess [18:13:46 CET] <dakar> that command errors out as well. i get: [18:13:46 CET] <dakar> Failed to open bitstream filter h264_mp4toannexb for stream 0 with codec copy: Invalid argument [18:13:47 CET] <dakar> [mpegts @ 01d7ec60] H.264 bitstream error, startcode missing [18:14:08 CET] <dakar> i was running: ffmpeg.exe -i 17540002.MOV -c copy -bsf:v h264_mp4toannexb -f mpegts 2.ts [18:14:21 CET] <alexpigment> fun [18:14:41 CET] <therage3> what's the ffprobe output for 7540002.MOV? [18:14:49 CET] <therage3> (pastebin it, don't copy it all here) [18:15:07 CET] <dakar> let me make sure i have the latest ffmpeg. some site suggests to make sure about that. [18:15:12 CET] <therage3> indeed [18:15:29 CET] <therage3> that being said, this command is from 2013 [18:15:43 CET] <therage3> so if it doesn't work because of outdated ffmpeg, your ffmpeg is woefully outdated :D [18:15:48 CET] <alexpigment> apparently sometimes you have to map the video and audio and copy them separately [18:15:54 CET] <alexpigment> https://trac.ffmpeg.org/ticket/2107 [18:15:58 CET] <therage3> ahhh yes [18:16:05 CET] <therage3> the wonderful world of video processing [18:17:21 CET] <dakar> okay i get errors with latest version as well. let me pastebin. [18:18:07 CET] <therage3> k [18:18:16 CET] <dakar> https://0bin.net/paste/18V57ROcjnyk0wPN#a92d-huUZHohZNSM2RHj0jw/BPgAROYlEmX… [18:19:14 CET] <alexpigment> the specs on this video are really weird [18:19:22 CET] <alexpigment> is this like a screen recording or something? [18:19:34 CET] <dakar> no, it's some portable recorder for classes [18:19:50 CET] <dakar> im not surprised it looks weird to you. [18:20:42 CET] <therage3> this is a very bizarre format, dakar [18:20:47 CET] <therage3> never seen anything like it [18:20:54 CET] <therage3> hmmmmmmmm [18:21:19 CET] <dakar> im willing to lose quality if that helps you guys help me. [18:21:19 CET] <SortaCore> alexpigment: well, I don't know how video works, but I'm writing a transcoder [18:21:37 CET] <SortaCore> atm I'm exposing the quality controls, so I need to know if I should warn the user if their parameters cancel out [18:21:38 CET] <dakar> it's a class, so as long as the text on the board and the audio are good enough, it's fine for me [18:22:42 CET] <alexpigment> dakar: well, here's the thing. you can make a temporary video that doesn't exhibit any noticable loss [18:22:45 CET] <alexpigment> it'll be very big [18:23:03 CET] <dakar> how big? i have 10 files that are about 1 gigabyte each. [18:23:32 CET] <dakar> i would prefer to deal with all of them at once. [18:23:36 CET] <therage3> that sounds suspiciously like VOB files on a DVD (the size, i mean) [18:23:37 CET] <alexpigment> 1 sec [18:24:00 CET] <SortaCore> one other question is how I get openh264 quality settings, does it support all of 'em [18:24:09 CET] <dakar> ~950mb and exactly 10 minutes each. the last one is shorter and smaller. [18:24:53 CET] <dakar> i'd like this step to be as fast as possible, even if it means larger files. handbrake is supposed to make them nicer eventually [18:25:07 CET] <alexpigment> ok, so look at the stackoverflow link from earlier: https://stackoverflow.com/questions/15908328/ffmpeg-to-combine-two-mov-file… [18:25:18 CET] <alexpigment> the OP has a simple command line [18:25:20 CET] <alexpigment> and he's trying to copy [18:25:42 CET] <alexpigment> instead of -vcodec copy, try -crf 10 [18:25:56 CET] <alexpigment> that should force it to re-encode the video [18:26:25 CET] <dakar> ffmpeg -i 'concat:17540002.MOV|17540003.MOV' -crf 10 -acodec copy test.mov [18:26:25 CET] <dakar> ? [18:27:12 CET] <dakar> not sure what this does, but it seems to be running. [18:27:15 CET] <dakar> i imagine this will take hours? [18:27:16 CET] <alexpigment> SortaCore: you generally don't need to worry about parameters cancelling out, assuming you're ok with ffmpeg handling that for you. one example would be preset and profile. by default, the ultrafast preset is baseline. if you specify high for your profile though, the two can't exist together. one of them stomps on the other [18:27:51 CET] <SortaCore> alexpigment: yea, superceding is fine, but I want to be able to warn the user if that happens [18:27:52 CET] <alexpigment> dakar: no idea how long it'll take. but crf 10 is fairly visually lossless. crf 0 is true lossless and i wouldn't really recommend that [18:28:11 CET] <dakar> i'm okay with lossy [18:28:21 CET] <dakar> as long as the text on the board is still fine [18:28:37 CET] <alexpigment> SortaCore: well, it can get kinda complicated. for example, if they have a target bitrate of 100mbps for 1080p H.264 and specify level 4.1, the bitrate violates the limits of level 4.1 [18:28:37 CET] <dakar> what does this give me eventually? [18:28:55 CET] <alexpigment> dakar: it gives you a big file in h.264 [18:29:07 CET] <alexpigment> you're just encoding now as opposed to later [18:29:30 CET] <alexpigment> if you really want to "fine tune" it with handbrake, just let me know what your settings are there. it's very easy to match the two [18:29:40 CET] <therage3> oh Lord [18:29:41 CET] <dakar> i'd really like to encode later, because I'd like to reduce the size and stuff (720p instead of whatever there is now, etc.) [18:29:41 CET] <therage3> handbrake [18:29:48 CET] <therage3> that nightmare from yesterday [18:29:48 CET] <therage3> jeez [18:30:04 CET] <therage3> i pray your mov's aren't telecined or interlaced or something [18:30:20 CET] <alexpigment> dakar: if you go to the advanced tab of handbrake, it'll say "x264 Encoder Options" at the bottom [18:30:40 CET] <alexpigment> in ffmpeg, just put -x264-params [copied options from handbrake] [18:31:02 CET] <dakar> cant find that. [18:31:05 CET] <alexpigment> ok [18:31:23 CET] <dakar> i assume CRF is the same as Constant Quality? I had it on 22 [18:31:27 CET] <alexpigment> yes [18:31:34 CET] <dakar> the preview looked good enough. [18:31:49 CET] <dakar> does this affect encoding time or just file size? [18:32:00 CET] <alexpigment> crf just affects file size [18:32:11 CET] <alexpigment> if you want the display size to be smaller, you use the -s parameter [18:32:16 CET] <alexpigment> e.g. 960x720 [18:32:17 CET] <dakar> let me ask you something, can i do the encoding for all the .mov files in handbrake and then concat them easily? [18:32:22 CET] <alexpigment> (since your source is 4x3) [18:32:39 CET] <alexpigment> technically yes [18:32:47 CET] <alexpigment> but you're making this harder/longer than it should be [18:32:59 CET] <alexpigment> just let me know what settings you want in handbrake, and i'll give you the ffmpeg command [18:35:28 CET] <dakar> okay so framerate untouched, CRF 25 or 22 whatever you suggest [18:35:48 CET] <alexpigment> that's all you need? [18:35:54 CET] <alexpigment> did you want to make it 720p or not? [18:36:45 CET] <dakar> let me see in the preview one second [18:37:31 CET] <dakar> resolution goes from 1728x1296 to 1280x960 [18:37:59 CET] <alexpigment> ffmpeg -i 'contact:video|video|video|etc' -s 1280x960 -crf 22 -c:a aac output.mp4 [18:38:17 CET] <alexpigment> there's obviously more fine tuning you can do, but if those are all the specs you need, that should work [18:38:42 CET] <alexpigment> i used aac because you seemed to have concerns about size, and there's really no reason to have PCM in your video from what I gather [18:38:53 CET] <alexpigment> (audio i mean) [18:40:09 CET] <dakar> it's a class, so theres some noise and the speaker isnt very clear, but quality doesnt really matter [18:40:18 CET] <alexpigment> right [18:40:32 CET] <alexpigment> i also realize i wrote "contact" up there for some reason ;) [18:40:33 CET] <alexpigment> but of course i meant concat [18:40:53 CET] <dakar> gonna try :) [18:42:30 CET] <dakar> okay it's running, probably take forever though [18:43:27 CET] <therage3> tell me about it. yesterday i transcoded 13 episodes from a TV show, about 23 minutes each. took 12 hours [18:43:40 CET] <dakar> i have 25 classes to go through. [18:43:42 CET] <dakar> this is just one [18:44:07 CET] <dakar> and this is an i7.. [18:44:24 CET] <alexpigment> well, if speed is a concern, you can add -preset veryfast [18:44:28 CET] <dakar> what would that do? [18:44:44 CET] <alexpigment> it would change some of the encoding parameters and make it encode faster [18:44:59 CET] <dakar> am i going to notice those? [18:45:14 CET] <alexpigment> generally speaking, when you encode with a faster preset, the quality suffers. but since we're specifying a constant quality value, it usually just means that the file size gets somewhat bigger to achieve the same quality [18:45:14 CET] <bencoh> at the expense of quality (if bitrate-constrained) or size (in crf case) [18:45:18 CET] <therage3> yes, but note that the quality will change ever so slightly, it is _not_ just a speed and filesize change as some people state [18:45:43 CET] <therage3> the quality change may be imperceptible though [18:45:57 CET] <therage3> (i just learned this yesterday in here...) [18:46:05 CET] <dakar> im not very concerned about the quality, crf 22 is apparently not really best to begin with [18:46:10 CET] <dakar> but worse than that would likely be too bad [18:46:32 CET] <alexpigment> ok, well, the crf is up to you [18:46:43 CET] <dakar> yeah, 22 is just fine [18:46:48 CET] <alexpigment> but yes, if encoding time is a concern, set -preset veryfast [18:47:09 CET] <alexpigment> (there's also ultrafast, but that sacrifices a lot to get to that speed) [18:47:11 CET] <bencoh> anyway, veryfast is usually "acceptable" in that kind of use [18:47:12 CET] <therage3> the general rule of thumb is, crf as high as you can stand before quality degradation makes it unacceptable, and preset as slow as you can stand [18:47:27 CET] <bencoh> and if not, hen try faster [18:47:31 CET] <dakar> asking again though, how bad is veryfast going to hurt the quality [18:47:32 CET] <bencoh> then* [18:47:41 CET] <alexpigment> dakar: you probably won't notice it [18:48:00 CET] <therage3> dakar: i'd do a visual test with both, it'll likely be very little if anything [18:48:20 CET] <dakar> how can i do a visual test for a few seconds of video? [18:48:30 CET] <dakar> veryfast is 2.5 times faster [18:48:32 CET] <alexpigment> put -t 30 in your command [18:48:40 CET] <alexpigment> that'll make a 30 second clip [18:48:43 CET] <therage3> if you're using handbrake, there's also a preview option [18:48:49 CET] <alexpigment> or that [18:49:44 CET] <dakar> ultrafast is just as good it seems [18:49:50 CET] <dakar> but the file size is 3 times bigger than veryfast [18:49:54 CET] <alexpigment> well, the file size will be pretty good [18:49:55 CET] <alexpigment> yeah [18:50:05 CET] <alexpigment> ultrafast is where size starts to become problematic [18:50:18 CET] <alexpigment> because it's stuck using baseline profile [18:50:27 CET] <therage3> iirc, with crf 16 and ultrafast, one file i was transcoding became _bigger than the original_ lol [18:50:35 CET] <therage3> that's no good [18:50:43 CET] <dakar> and apparently, for some reason, no preset is larger than veryfast (6mb vs 5mb) [18:50:59 CET] <alexpigment> therage3: yeah, that's going to depend on the source. in his case, it sounds like the source has a really high bitrate to begin with [18:51:22 CET] <therage3> alexpigment: yeah. mine was that &$&% cartoon :) [18:51:32 CET] <dakar> make it grayscale :D [18:51:38 CET] <dakar> okay i'll go with veryfast then [18:52:05 CET] <alexpigment> therage3: right. it just comes down to how noisy/lossy the original stuff is, and its original bitrate. there are cases where crf 1 will make a much smaller file size than the original [18:52:15 CET] <therage3> yeah [18:52:48 CET] <therage3> alexpigment: and speaking of this, i was also going to experiment with handbrake's noise removal thingie, since this cartoon is slightly grainy in spots [18:53:14 CET] <alexpigment> therage3: that's certainly an option. unless file size is an issue though, i wouldn't worry about it [18:53:33 CET] <alexpigment> lack of grain sets my bs detector off, so i generally prefer not removing it [18:54:03 CET] <dakar> out of curiosity, when ffmpeg is running it mentions bitrate, is that the bitrate of the video? [18:54:10 CET] <alexpigment> yeah [18:54:22 CET] <alexpigment> crf automatically determines the bitrate based on the complexity of the frames [18:54:24 CET] <dakar> isnt 3~4k pretty high for my type of content? [18:54:38 CET] <alexpigment> not to me, but that's what the CRF is there for [18:54:43 CET] <dakar> also, isnt average bitrate better for this? [18:54:49 CET] <therage3> alexpigment: you mean lack of grain indicates highly digitally processed video or something? [18:55:01 CET] <dakar> okay, it died [18:55:19 CET] <dakar> [h264 @ 000000ce3d5c0380] Error splitting the input into NAL units. [18:55:19 CET] <dakar> [h264 @ 000000ce3debb1a0] Invalid NAL unit size (-472435572 > 12460). [18:55:19 CET] <alexpigment> dakar: not usually [18:55:19 CET] <dakar> Error while decoding stream #0:0: Invalid data found when processing input [18:55:38 CET] <dakar> the output file is exactly 10 minutes. [18:55:46 CET] <dakar> looks like it did one file and then died on me [18:55:50 CET] <alexpigment> therage3: yeah. it has a distinct look that feels processed to me. i prefer to have the original grain, although file size gets bigger when preserving grain [18:55:58 CET] <alexpigment> dakar, that's what it sounds like [18:56:02 CET] <alexpigment> googling now [18:56:18 CET] <dakar> i checked the files now, it is indeed just the first file [18:56:20 CET] <therage3> alexpigment: interesting... a friend of mine also into this show noticed some digitally processed copies uploaded on YouTube and he also says they look "artificial" [18:56:27 CET] <dakar> and it went from 950mb to 212mb [18:56:46 CET] <alexpigment> therage3: yeah youtube's quality sucks in general, so i get that feeling from most everything i watch on yt [18:56:58 CET] <dakar> i wonder if it would make sense to do this for all files and then mess with combining them [18:57:24 CET] <alexpigment> dakar: possibly. still googling [18:57:41 CET] <therage3> alexpigment: lol [18:58:57 CET] <dakar> therage3 it sounds funny but i already a lot of time googling simply because i had no idea what to look for [18:59:26 CET] <alexpigment> dakar: out of curiosity, is this a 32-bit ffmpeg? [18:59:41 CET] <alexpigment> that was mentioned on one thread about this error [18:59:41 CET] <dakar> alexpigment ffmpeg-20171204-71421f3-win64-static [18:59:44 CET] <alexpigment> k [18:59:48 CET] <therage3> tell me about it... and the problem with info on Google is a) people are often clueless, b) the information is scattered so you have to make it one cohesive thing [19:00:04 CET] <therage3> we lost so much time yesterday with a detelecine thing on handbrake [19:00:08 CET] <dakar> therage3 video encoding is one of those topics that you need to know quite a lot to handle the basics [19:00:08 CET] <therage3> because there was weird information everywhere [19:00:19 CET] <therage3> dakar: oh god yes, i'm learning that now [19:00:30 CET] <therage3> yesterday was when i felt like i was getting a doctorate in this channel [19:00:36 CET] <therage3> lol [19:00:36 CET] <dakar> the annoying part is that im not even remotely interested in this.. [19:00:40 CET] <dakar> i just want to get something done =/ [19:01:01 CET] <alexpigment> dakar: can you see if just trying to encode video 2 causes the problem to happen? [19:01:29 CET] <alexpigment> i'd like to know if this is the result of concatting those particular files, or if the start of video 2 is just generally bad [19:01:33 CET] <dakar> alexpigment i just tried to process the second file on its own. i get the same error at the end. [19:01:48 CET] <dakar> but i do get a working 10 minutes file at the end [19:01:50 CET] <alexpigment> but it did create it successfully? [19:01:51 CET] <alexpigment> ok [19:02:06 CET] <alexpigment> and the source files are all 10 minutes each? [19:02:13 CET] <dakar> except the last one of every class that's smaller [19:02:17 CET] <alexpigment> i see [19:03:46 CET] <alexpigment> dakar: well, i have no idea what's causing this particular error [19:04:00 CET] <alexpigment> others here are much more knowledgeable than i am, and maybe could help [19:04:02 CET] <dakar> any idea how to concat some files that are the output of this? [19:04:14 CET] <alexpigment> but it sounds like you have the option to concat the results [19:04:15 CET] <alexpigment> yes [19:04:20 CET] <alexpigment> https://trac.ffmpeg.org/wiki/Concatenate#demuxer [19:04:32 CET] <alexpigment> look at the section that says "using intermediate files" [19:05:59 CET] <dakar> ffmpeg -i "concat:output2.mp4|output3.mp4" -c copy -bsf:a aac_adtstoasc 2n3.mp4 [19:06:06 CET] <alexpigment> in retrospect, if we had known that this would fail, it would have been better to make the ts in the first place [19:06:11 CET] <dakar> this runs for 1 second, finishes without errors, creates a file that is practically bad [19:06:14 CET] <alexpigment> yeah, that should work [19:06:22 CET] <alexpigment> practically bad = ? [19:07:15 CET] <dakar> identical to output2.mp4 [19:07:25 CET] <alexpigment> oh, i just noticed you're using the mp4 [19:07:33 CET] <alexpigment> did you see the section i mentioned? [19:07:40 CET] <dakar> Using intermediate files, yes [19:07:40 CET] <alexpigment> you need to temporarily convert to mpegts [19:07:45 CET] <dakar> ow. [19:07:54 CET] <alexpigment> ok, so let's rethink the gameplan here [19:07:57 CET] <dakar> so i have to go .mov to .mp4 to .ts, then to mp4? [19:08:03 CET] <alexpigment> you're going to go through two steps at least [19:08:12 CET] <dakar> im fine with 2 steps as long as it works lol [19:09:36 CET] <alexpigment> ffmpeg -i [sourcevideo] -s 1280x960 -crf 22 -c:a aac -preset veryfast -f mpegts video1.ts [19:10:13 CET] <dakar> fwiw, the .mov to .mp4 took a few minutes, then .mp4 to .ts took a second, then concatting 2 .ts to one .mp4 took a second [19:10:20 CET] <dakar> so it looks like a good plan [19:10:25 CET] <alexpigment> do that for each video. at the end, just do the following: ffmpeg -f mpegts -i "concat:video1.ts|video2.ts" -c copy -bsf:a aac_adtstoasc output.mp4 [19:10:35 CET] <alexpigment> ok, so if you're fine converting the mp4 to ts, that's cool [19:10:39 CET] <alexpigment> it's just a container swap. there's no re-encoding [19:11:03 CET] <alexpigment> but knowing what we know now, you can simply the process as I mentioned above, by simply making the ts files first instead of the mp4 files [19:11:10 CET] <dakar> you basically added -f mpegts to the previous thing so it gives .ts instead of mp4 eventually? [19:11:12 CET] <alexpigment> then combining the ts files with ffmpeg afterward [19:11:21 CET] <alexpigment> dakar: basically [19:11:32 CET] <alexpigment> it's even implied with the output file name [19:11:42 CET] <alexpigment> but i figured i'd specify it just in case it does something with the bitstream filters [19:12:06 CET] <dakar> you also changed -bsf:v to -bsf:a, why? [19:12:19 CET] <dakar> or did i miss something [19:12:43 CET] <alexpigment> that bsf converts the aac audio from a format which is appropriate for ts to a format which is appropriate for mp4 [19:12:47 CET] <alexpigment> it's lossless [19:13:28 CET] <dakar> okay, time to work on this then [19:13:31 CET] <dakar> seems like i have the recepie [19:14:00 CET] <therage3> hm [19:14:31 CET] <therage3> i may need to remember that bsf thing later, i've often just transcoded video to mkv and stream-copied the audio [19:14:36 CET] <SortaCore> alexpigment: should the user always specify level with profile? [19:14:51 CET] <dakar> btw, can i simply rename .mp4 to .mkv at the end of the process? it's just a container and should work just fine, correct? [19:15:10 CET] <alexpigment> SortaCore: most people don't. it's only needed for hardware compatibility, and in some cases, software compatibility [19:15:33 CET] <alexpigment> dakar: yeah, if you want to set the output to .mkv, that's fine [19:16:00 CET] <dakar> alexpigment i mean simply rename the files [19:16:01 CET] <alexpigment> just to be clear, you're talking about renaming the output file in the command line, right? [19:16:04 CET] <therage3> setting the output is one thing, can they just change the extension? [19:16:07 CET] <therage3> that's what dakar is asking i think [19:16:18 CET] <dakar> yeah im not going to redo 5 files for this ;) [19:16:38 CET] <alexpigment> ok, so when you concat later on [19:16:47 CET] <alexpigment> it says "output.mp4" up there in the command [19:16:52 CET] <alexpigment> just put "output.mkv" [19:16:59 CET] <dakar> and ffmpeg will take care of making it proper mkv? [19:17:02 CET] <therage3> yes [19:17:03 CET] <alexpigment> yeah [19:17:07 CET] <dakar> awesome [19:17:09 CET] <therage3> it will use appriopriate wrappers for the mkv container [19:17:13 CET] <therage3> instead of mp4 container [19:17:44 CET] <therage3> if you manually change the extension later on, maybe things like VLC could handle it because VLC just bruteforces everything and tries to play whatever it can [19:17:48 CET] <therage3> but another player may fail [19:17:57 CET] <dakar> okay [19:18:52 CET] <SortaCore> so if some weirdo wants to use the level 1B [19:18:54 CET] <SortaCore> how do [19:19:00 CET] <alexpigment> 1B? [19:19:08 CET] <SortaCore> yea, it's a thing [19:19:10 CET] <alexpigment> oh, i guess that's a thing [19:19:18 CET] <alexpigment> does -level 1b work? [19:19:26 CET] <alexpigment> honestly, i've never used 1b ever [19:19:44 CET] <SortaCore> even if it does, I'm doing C++, and the level is a number type @.@ [19:20:04 CET] <alexpigment> so 1b only supports a resolution of 128x96 and 30fps max [19:20:19 CET] <alexpigment> https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels [19:20:30 CET] <alexpigment> so that chart is invaluable [19:20:57 CET] <alexpigment> the main things you need to look at are the max bitrate, the max resolution and corresponding frame rate [19:21:38 CET] <alexpigment> this is why this stuff gets confusing and it's best to let ffmpeg just kinda handle it like it does [19:23:17 CET] <alexpigment> and just to make matters more confusing, there are additional profiles (e.g. high444pp) that have different restrictions for bitrates than is listed in this chart [19:23:28 CET] <alexpigment> the official spec has the multipliers that you can use [19:24:15 CET] <alexpigment> (e.g. when using [whatever special profile], bitrates can be 1.5x of main profile when using level 4.1) [19:24:33 CET] <alexpigment> that's just made up, but i remember the limits being referenced that way [19:25:21 CET] <Rajko> is the emulation prevention byte present in also length-prefixed h264 bitstreams ? or just annex-b [19:32:09 CET] <SortaCore> I'm sure my users will enjoy researching that [19:36:20 CET] <alexpigment> sortacore: well, here's the thing [19:36:26 CET] <alexpigment> 99% of people don't set a level [19:36:53 CET] <alexpigment> people don't understand what a level is, it's effect on the resolution and bitrate, etc [19:37:24 CET] <alexpigment> but sometimes they see something on the internet that says "high level 4.1" in supported video formats [19:37:34 CET] <alexpigment> so you want them to be able to select that so they feel warm and fuzzy inside [19:37:47 CET] <SortaCore> it's not just compatibility, isn't it also advanced algorithm = slower decode? [19:37:56 CET] <SortaCore> more CPU footprint? [19:38:12 CET] <alexpigment> maybe technically [19:38:18 CET] <alexpigment> but it's a higher bitrate [19:38:23 CET] <alexpigment> so probably a slower decode because of that [19:38:39 CET] <alexpigment> and of course, slower decode due to higher resolution [19:39:08 CET] <alexpigment> but it's like you have device A that was only rated to play 640x480 videos at a particular bitrate [19:39:24 CET] <alexpigment> and you have device B that was rated to play 1280x720 videos at a particular bitrate and frame rate [19:39:48 CET] <alexpigment> it's really just a way for someone to go "oh, this video should play on this device" [19:40:12 CET] <alexpigment> it's usually a *derived* element [19:40:28 CET] <alexpigment> the encoder sees what specs it ended up with and appends the corresponding level based on that [19:40:40 CET] <SortaCore> looks like x264 parses 1B as 0.9 [19:41:00 CET] <alexpigment> interesting [19:50:57 CET] <SortaCore> so does NVENC [19:56:02 CET] <BtbN> the level setting is only ever a limit [19:56:13 CET] <BtbN> And usually encoders will automatically set the lowest level for what they are doing [20:04:33 CET] <AlecTaylor> hi [20:04:52 CET] <AlecTaylor> How do I use ffmpeg to stream webcam to http:// and file? - https://superuser.com/q/1274570 [20:06:04 CET] <BtbN> you don't stream to http [20:09:26 CET] <Rajko> BtbN, you actually can. [20:10:15 CET] <Rajko> its used in a couple of places where you stream to "a http url" i dont remember what it actually does but i think http chunked encoding transfers are in play [20:10:26 CET] <Rajko> i think its only viable -f flv [20:10:48 CET] <klaxa> yes if you pass -listen 1 you can "stream" a file to _one_ client over http [20:10:54 CET] <AlecTaylor> Rajko: Happy to switch to any codec to make this work [20:11:00 CET] <klaxa> until the client quits of the file ends [20:11:15 CET] <BtbN> http is just not make for video streaming. Use something more appropiate [20:11:30 CET] <BtbN> If you absolutely must use http, generate a hls playlist and serve it via some proper http server [20:11:35 CET] <AlecTaylor> Well how about chucking to a file, then I can serve that file as a static file in my web server, which will stream to the client right// [20:11:36 CET] <AlecTaylor> ? [20:11:53 CET] Action: AlecTaylor is using nginx [20:13:03 CET] <klaxa> i think if you want to play it in a website you will need a js hls player [20:13:19 CET] <AlecTaylor> klaxa: Doesn't the new video tags support streaming videos? [20:13:22 CET] <AlecTaylor> *Don't [20:15:02 CET] <klaxa> https://developer.mozilla.org/en-US/Apps/Fundamentals/Audio_and_video_deliv… [20:15:11 CET] <klaxa> doesn't look like any browser supports hls without js [20:17:37 CET] <AlecTaylor> klaxa: Okay well happy to use a JS player then. My app is in Angular, so shouldn't be too difficult to integrate one. [20:18:17 CET] <AlecTaylor> klaxa: So what's the command I should be using to chunk it to a file, and then I'll just use the file path from nginx? - Or is there something extra needed? [20:18:44 CET] <klaxa> ffmpeg -i whatever [<whatever>] -f hls some/path/to/readable/webroot/master.m3u8 [20:18:45 CET] <klaxa> i think [20:20:10 CET] <klaxa> your hls player will want the url on your webserver to the m3u8 file [20:25:13 CET] <jfmcarreira> heyyy guys. whats is the minimum version to use the new libavcodec api? [20:26:46 CET] <JEEB> the push/pull API? [20:26:57 CET] <JEEB> I think it was 3.1 which was first branched after that API was added [20:43:08 CET] <AlecTaylor> klaxa: Thanks that seems to be working [20:57:12 CET] <zamba> when using ffmpeg -s 00:00:10.0 -i <input> -to 00:23:42.0 -c copy <output> i notice that the time counter is way off in the destination file [20:57:17 CET] <zamba> what could be causing this? [21:15:26 CET] <dakar> i think -s is for resolution? [21:15:32 CET] <alexpigment> dakar: yes [21:15:50 CET] <alexpigment> think "size" if that helps you remember it [21:16:15 CET] <alexpigment> zamba: is the time counter correct if you omit -c copy? [21:17:46 CET] <dakar> i was mentioning this to zamba [21:17:53 CET] <dakar> he was using -s 00:00:10.0 [21:17:58 CET] <alexpigment> oh gotcha [21:18:02 CET] <dakar> and said the timer was off [21:18:09 CET] <alexpigment> -ss is what i usually use [21:18:21 CET] <zamba> i meant -ss, yes :) [21:18:32 CET] <alexpigment> anyway, does it cut correctly if you omit -c copy? [21:18:32 CET] <dakar> i'm already encoding the 4th class :) [21:18:39 CET] <alexpigment> dakar: nice :) [21:18:43 CET] <dakar> even made a batch script to handle the errors lol [21:18:44 CET] <zamba> alexpigment: doesn't that imply reencoding? [21:18:57 CET] <alexpigment> zamba: yes, but it also helps identify the issue [21:19:11 CET] <zamba> alexpigment: ah, ok [21:19:14 CET] <alexpigment> maybe i'm wrong in this assumption, but ffmpeg probably has to cut on keyframes [21:19:18 CET] <alexpigment> when doing it losslessly [21:19:36 CET] <dakar> every 1h30mins becomes a nicely packed ~2gb mkv file and veryfast is doing great [21:19:37 CET] <alexpigment> if your source has really long GOPs, then then cut could be way off [21:20:18 CET] <alexpigment> dakar: awesome. glad that's working for you. i think there's probably an easier way to do it all still, but if you've got a batch file, then that takes away most of the complexity [21:20:44 CET] <dakar> yeah must be better way [21:20:59 CET] <dakar> but this works so i rather let it do its magic instead of spending time figuring a better way [21:21:30 CET] <alexpigment> i tend to agree with that sentiment [21:22:50 CET] <dakar> i'd usually spend the time and effort to better it, but it's a one-time mission so wth [21:23:03 CET] <alexpigment> gotcha [21:33:58 CET] <therage3> dakar: how is that going? [21:55:19 CET] <dakar> therage3 smooth so far [23:51:37 CET] <SortaCore> so the rtsp -> avframe [23:51:42 CET] <SortaCore> can that be any pixel format? [23:51:55 CET] <SortaCore> atm I'm getting it only as YUV420P, and for HWA I have to convert them to NV12 [23:52:11 CET] <SortaCore> but some peeps keep saying rtsp doesn't select a pixel format [23:53:43 CET] <sfan5> rtsp is a container, it doesn't have a pixfmt by definition [23:54:09 CET] <illegal> https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio [23:54:11 CET] <illegal> " When compatibility with hardware players doesn't matter then use libvorbis in a MKV container when libfdk_aac isn't available. " [23:54:30 CET] <illegal> Why? [23:55:47 CET] <alexpigment> illegal, i think it's basically just saying that libfdk_aac is a very good aac encoder [23:56:24 CET] <alexpigment> and that unless you need aac, you might use libvorbis if fdk_aac isn't an option (e.g. due to licensing reasons) [23:56:42 CET] <furq> the line below that should really be merged into that line [23:56:54 CET] <alexpigment> with that being said, i don't know how old this article is, but the built-in aac encoder in FFMPEG is very good at this point [23:56:57 CET] <furq> yeah [23:56:57 CET] <illegal> Correct, but I am confused as to why if hardware compatibility doesn't matter and he saying that lipopus would yield higher quality he would still basically say that you should use libfdk_aac [23:57:01 CET] <furq> i mean it's still recommending vorbis [23:57:11 CET] <illegal> I am not saying he is wrong or anything, I am just wondering why really [23:57:16 CET] <furq> illegal: most things that support h264 only support aac audio in mp4 [23:57:17 CET] <illegal> seems odd [23:57:35 CET] <furq> web browsers and apple devices, for starters [23:57:41 CET] <alexpigment> apple for sure [23:57:56 CET] <furq> well chrome doesn't support h264+opus in mkv [23:58:03 CET] <furq> and idk if that's a thing yet in mp4 [23:58:20 CET] <furq> if it is then i doubt any of the browsers are that cutting edge [23:58:23 CET] <llogan> that article is a little sloppy [23:58:29 CET] <furq> most of the wiki is a bit sloppy [23:58:41 CET] <alexpigment> i think it's a little out of date and doesn't really tell why it recommends x over y [23:58:48 CET] <llogan> this one is above the slop avg [23:58:51 CET] <alexpigment> i personally have no use for actual vorbis audio ever [23:58:51 CET] <furq> basically use opus if you don't care about compat and fdk or aac if you do [23:59:01 CET] <alexpigment> and opus is cool if i have some reason to use it, but i consistently never do [23:59:02 CET] <illegal> I'll check on chrome to see if it's true, I know youtube uses opus so I don't know why chrome wouldn't support mkv+opus [23:59:17 CET] <furq> because it doesn't support mkv [23:59:21 CET] <illegal> ah [23:59:38 CET] <furq> it supports vp8/9 and opus in webm or h264 and aac in mp4 [23:59:42 CET] <furq> anything else is questionable [00:00:00 CET] --- Wed Dec 6 2017

1 0

ffmpeg-devel.log.20171204
by burek 05 Dec '17

05 Dec '17

[00:02:29 CET] <durandal_1707> it could be used as such., need to check out if it indeed solves problems [00:03:14 CET] <durandal_1707> its there mainly for properly marking frames [00:19:21 CET] <atomnuker> you know I'm starting to think maybe it'll be a good idea to have some generic side-data like thing internal to lavc [00:19:40 CET] <atomnuker> could even be a side data wrapping a internal ffmpeg only side data [00:19:56 CET] <atomnuker> then we could have filters which could pass data to one another [00:20:07 CET] <atomnuker> and even codec -> filter or codec -> demuxer [00:24:33 CET] <durandal_1707> dont, you are like nicolas [00:26:34 CET] <iive> atomnuker: how is palette passed though filters? [00:30:07 CET] <atomnuker> iive: dunno, an avframe field? [00:30:26 CET] <atomnuker> I should probably tell you I know nothing of palette formats [00:30:35 CET] <iive> i'm asking since afair palette is sent as side data. [00:30:41 CET] <atomnuker> it is? [00:30:55 CET] <iive> might be wrong. [00:31:15 CET] <atomnuker> I think they're sent under avframe->data[1] [00:31:24 CET] <atomnuker> I don't see any palette side data [00:31:27 CET] <iive> or [3] [00:31:47 CET] <iive> yeh, ignore me. [00:58:18 CET] <wm4> atomnuker: what would that generic side data thing do? [00:58:39 CET] <wm4> I think palette is in data[1] [00:58:58 CET] <wm4> fun fact: even some not paletted formats require a palette [00:59:02 CET] <wm4> (pseudopal flag) [00:59:13 CET] <JEEB> gotta love that stuff [00:59:19 CET] <JEEB> I think we had some fun with that with DShow [00:59:19 CET] <wm4> I think all 8 bit formats have this, because you can treat them as paletted if you want to [01:27:54 CET] <atomnuker> BBB: when does vp9 signal stuff like resolution, colorspace, etc? on keyframes only? [02:16:39 CET] <tmm1> jkqxz: what is the "hw-config metadata" you mentioned in http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221601.html [02:19:03 CET] <jkqxz> tmm1: <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/mediacodecdec.c;h…>. You're adding AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX. [02:23:59 CET] <tmm1> got it, thanks [02:24:18 CET] <tmm1> should i leave AD_HOC in there and or them? [02:24:34 CET] <jkqxz> (Being able to use that to determine the support is why wm4 asked for the feature in the first place, I think.) [02:26:18 CET] <tmm1> i'll replace ad_hoc [02:26:27 CET] <jkqxz> I removed it from others, it's mostly a placeholder. [02:26:30 CET] <jkqxz> Yeah. [02:33:12 CET] <jkqxz> tmm1: Needs device_type to be set too. [02:42:50 CET] <tmm1> oops [02:43:07 CET] <tmm1> fixed locally [03:35:27 CET] <BBB> atomnuker: yes [03:35:55 CET] <BBB> atomnuker: inter frames can signal resolution change, but they can also signal resolution taken from a reference, and in 99.9% of the cases thats what happens (because its 1 bit instead of 2x16) [03:42:24 CET] <stevenliu> src/libavfilter/x86/vf_threshold.asm:75: error: invalid number of operands [03:42:36 CET] <stevenliu> Darwin liuqideMacBook-Pro.local 17.2.0 Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017; root:xnu-4570.20.62~3/RELEASE_X86_64 x86_64 [03:43:00 CET] <stevenliu> 150 rm -rf * [03:43:00 CET] <stevenliu> 151 ../configure --enable-fontconfig --enable-gpl --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libspeex --enable-libx264 --enable-libx265 --enable-libfdk-aac --enable-version3 --cc='ccache gcc' --enable-nonfree --enable-videotoolbox [03:43:00 CET] <stevenliu> 152 make -j2 [03:45:04 CET] <stevenliu> Hi guys, I get error when complie the FFmpeg, i get the newest code one minute ago, on OS X. [03:47:03 CET] <jamrial> what's your nasm/yasm version? [03:47:58 CET] <stevenliu> liuqideMBP:xxx liuqi$ yasm --version [03:47:58 CET] <stevenliu> yasm 1.3.0 [03:47:59 CET] <stevenliu> Compiled on Apr 28 2016. [03:48:00 CET] <stevenliu> Copyright (c) 2001-2014 Peter Johnson and other Yasm developers. [03:48:02 CET] <stevenliu> Run yasm --license for licensing overview and summary. [03:48:04 CET] <stevenliu> liuqideMBP:xxx liuqi$ nasm -v [03:48:06 CET] <stevenliu> NASM version 0.98.40 (Apple Computer, Inc. build 11) compiled on Oct 11 2017 [03:48:39 CET] <stevenliu> do i need update my yasm? [03:48:49 CET] <jamrial> no, yasm is the latest version [03:48:54 CET] <stevenliu> nasm? [03:48:56 CET] <jamrial> i don't recognize that nasm version, though [03:49:38 CET] <jamrial> what's is X86ASM set to in config.mak? [03:50:20 CET] <stevenliu> X86ASM=yasm Ah, yasm [03:51:49 CET] <stevenliu> let me try use nasm [03:52:01 CET] <stevenliu> --x86asmexe=nasm [03:52:05 CET] <jamrial> huh, curious, it really doesn't work with yasm [03:52:10 CET] <jamrial> http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-yasm [03:52:45 CET] <jamrial> stevenliu: nasm is default, so it used yasm instead it means your nasm version is too old [03:53:14 CET] <stevenliu> mhmm, let me update it [03:59:29 CET] <jamrial> stevenliu: try replacing pblendvb with PBLENDVB in that file [04:00:16 CET] <stevenliu> I have update to newest nasm, will try "try replacing pblendvb with PBLENDVB in that file" later [04:17:17 CET] <cone-856> ffmpeg 03Carl Eugen Hoyos 07master:894f1c399b5f: lavf/mov: Fix missing newline. [04:35:58 CET] <stevenliu> jamrial: PBLENDVB is ok. [05:01:18 CET] <cone-856> ffmpeg 03Robert Nagy 07master:31b351ea81d0: avformat/hlsenc: fix baseurl missing last char [05:24:54 CET] <cone-856> ffmpeg 03Steven Liu 07master:071f47649ce3: avformat/hlsplaylist: add int type of API ff_hls_write_file_entry [05:24:55 CET] <cone-856> ffmpeg 03Steven Liu 07master:ad6946b8189e: avformat/hlsplaylist: add return value check of strftime [05:24:56 CET] <cone-856> ffmpeg 03Steven Liu 07master:1cfde7abd000: avformat/dashenc: add avpriv_io_move return value check [06:23:35 CET] <cone-856> ffmpeg 03James Almer 07master:b73304f79eba: x86vf_threshold/: use the PBLENDVB macro [06:23:48 CET] <atomnuker> jamrial: what do you think the saturation functions should bump in version.h? [06:23:54 CET] <atomnuker> minor/micro? [06:24:23 CET] <jamrial> new functions in an installed header, so minor [07:21:26 CET] <atomnuker> daddesio: yeah, no, the last patch's no-go [07:21:45 CET] <atomnuker> "As a work-around for this issue, the decoder MAY choose not to apply the 180-degree phase shift" [07:22:19 CET] <atomnuker> or maybe it should be made an option [07:22:29 CET] <atomnuker> I think I'll make it into an option [07:25:02 CET] <daddesio> I agree it might be good to give the user the option. [07:25:18 CET] <daddesio> because it's not what I would expect. [07:32:05 CET] <daddesio> we also have to update FATE (specifically: testvector05.f32, testvector06.f32, and testvector12.f32). [07:49:07 CET] <atomnuker> yes, I know, that's what I'm doing [07:49:19 CET] <atomnuker> I'm replacing all samples and references [07:50:26 CET] <atomnuker> and because vorbis sucks so much the test samples are conveniently provided as a raw <bytes_for_packet><packet> bitstream which does mean I have to write a simple program to mux them to something usable [08:09:46 CET] <daddesio> atomnuker: You can find .opus versions of the testvectors here: https://people.xiph.org/~greg/opus_testvectors/ [08:10:22 CET] <daddesio> although the first one (testvector01.bit.opus) seems to have screwed up timestamps which causes warning in ffmpeg/avconv. the rest are fine. [08:11:22 CET] <daddesio> JSYK, none of the .bit files changed in RFC8251, only the .dec (PCM output) files. [08:18:40 CET] <atomnuker> those are 5 years old mate, I'm doing the new testvectors from the rfc [08:18:47 CET] <atomnuker> they didn't? [08:18:56 CET] <atomnuker> oh well, nvm [08:31:22 CET] <cone-856> ffmpeg 03Andrew D'Addesio 07master:9b45bcf713e0: libavutil: Add saturating subtraction functions [08:31:23 CET] <cone-856> ffmpeg 03Andrew D'Addesio 07master:511e6f17f493: opus_silk: Fix arithmetic overflow (per RFC8251) [08:31:24 CET] <cone-856> ffmpeg 03Andrew D'Addesio 07master:de052ea454e0: opus_celt: Fix arithmetic overflow (per RFC8251) [08:31:25 CET] <cone-856> ffmpeg 03Andrew D'Addesio 07master:fe05f93013c4: opus: Add Special Hybrid Folding (per RFC8251) [08:31:26 CET] <cone-856> ffmpeg 03Rostislav Pehlivanov 07master:1b8649c2ce95: opus: add an option to toggle intensity stereo phase inversion [08:31:27 CET] <cone-856> ffmpeg 03Rostislav Pehlivanov 07master:d1d6f965d81b: fate-opus: update to match the changes from RFC8251 [08:32:18 CET] <atomnuker> michaelni: could you update the fate .dec references in opus to the new versions from https://www.ietf.org/proceedings/98/slides/materials-98-codec-opus-newvecto… [08:33:21 CET] <atomnuker> take the testvector##.dec files rather than the testvector##m.dec, the latter ones are for decoding with the apply_phase_inv flag off [08:33:58 CET] <atomnuker> the tron 6ch sample doesn't need to be updated [08:37:32 CET] <daddesio> did these patches just go into master? I don't see it in git.ffmpeg.org. [08:40:32 CET] <atomnuker> I think that one's a mirror to http://git.videolan.org/?p=ffmpeg.git;a=log;h=HEAD [08:40:50 CET] <atomnuker> so its git.videolan.org - > git.ffmpeg.org -> (eventually) github.com/ffmpeg/ffmpeg [08:41:50 CET] <daddesio> ah, I see, cool https://git.videolan.org/?p=ffmpeg.git;a=summary [08:46:00 CET] <daddesio> You might want to be smarter about only dropping the phase shift when it's detected that the stereo CELT frame is going to (eventually, by FFmpeg) be downmixed to one channel. [08:46:17 CET] <daddesio> for multi-channel audio, I mean [08:46:36 CET] <daddesio> because some CELT frames might be downmixed and some might not. [08:47:10 CET] <daddesio> wait [08:49:33 CET] <atomnuker> I'm pretty sure downmixing is dead code [08:49:43 CET] <atomnuker> none of the fate samples trigger the code to do it [08:51:02 CET] <daddesio> It's not dead. If you take a stereo Opus file and modify the OggOpus header to say it's mono, then it will downmix to mono. [08:52:49 CET] <daddesio> but yeah, you are passing the same c->apply_phase_inv to each CELT frame. But you could totally look at avctx->request_channel_layout to see if this (stereo) CELT frame is mapped to one output channel ... I think. I'm not familiar with request_channel_layout. [08:53:35 CET] <daddesio> that way it's not like the entire (multichannel) Opus file will drop the phase shift. [08:54:07 CET] <atomnuker> none of the test samples are broken if I disable all downmixing code [08:54:15 CET] <atomnuker> they're meant to test every case, right? [08:54:21 CET] <daddesio> erm [08:54:38 CET] <daddesio> I thought FATE just had the RFC testvectors, plus a multichannel example. [08:54:49 CET] <daddesio> the testvectors are all stereo. [08:55:46 CET] <daddesio> Admittedly I'm not aware of a real-world Opus file that claims it's mono but has stereo CELT frames. [08:56:16 CET] <atomnuker> if they're meant to handle all aspects of the opus decoder then how come they don't handle downmixing? [08:57:04 CET] <daddesio> because no real-world files use that feature? :P [08:57:32 CET] <daddesio> you can create a test tho [08:58:47 CET] <daddesio> just take any stereo .opus file and change the "Channel Count" field from 2 to 1 (https://tools.ietf.org/html/rfc7845.html#section-5.1) and our Opus decoder will downmix the CELT frames to one mono output. [08:59:59 CET] <daddesio> going to bed now since I have work tomorrow. [10:31:40 CET] <cone-856> ffmpeg 03Paul B Mahol 07master:86fda8be3f38: avfilter: add hflip x86 SIMD [10:35:37 CET] <atomnuker> durandal_1707: that was a bit premature [10:35:58 CET] <durandal_1707> what? [10:35:59 CET] <atomnuker> why do you load 2 regs at once and then do exactly the same things to them? [10:36:09 CET] <atomnuker> also RET should be indented [10:37:02 CET] <atomnuker> wouldn't loading 2 regs at the same time unconditionally also increase padding requirements? [10:37:09 CET] <durandal_1707> atomnuker: it should be faster that way [10:37:24 CET] <atomnuker> it usually isn't [10:37:32 CET] <atomnuker> also most of the movs should be aligned [10:37:54 CET] <atomnuker> *most of them == all of them [10:38:08 CET] <durandal_1707> it cant be aligned if height is not multiple of mmsize [10:38:22 CET] <atomnuker> you mean width? [10:39:12 CET] <durandal_1707> one could write special version for width multiple of mmsize [10:39:59 CET] <durandal_1707> but for what gain? [10:40:01 CET] <atomnuker> this is irrelevant [10:40:48 CET] <atomnuker> I'm pretty sure this asm is quite broken [10:41:08 CET] <durandal_1707> also one can use crop and it will be unaligned [10:41:09 CET] <atomnuker> seeing as you require a 2*mmsize padded width [10:41:56 CET] <durandal_1707> atomnuker: no, its faster than what clang gives, so i declare it state of art [10:42:17 CET] <durandal_1707> if you can improve it even more, patch welcome [10:43:03 CET] <atomnuker> I meant broken, as it _crashes_ [10:43:22 CET] <durandal_1707> it works here [10:43:50 CET] <atomnuker> with arbitrary resolutions like 531 or 1011? [10:43:53 CET] <atomnuker> *width [10:45:42 CET] <michaelni> atomnuker, about opus testvectors, i cannot upload them as is as they overwrite existing ones and break fate of all past revissions [10:47:53 CET] <atomnuker> so samples can only be added or removed, not replaced? [10:48:30 CET] <nevcairiel> only added, not removed either [10:49:09 CET] <atomnuker> why, what would happen if they did get removed after say, 2 years? [10:49:31 CET] <nevcairiel> if you try to bisect some older issue your fate run gets all sorts of broken [10:49:46 CET] <durandal_1707> atomnuker: i tried various widths and it works [10:50:16 CET] <nevcairiel> but if the references change you can add them as v2 or whatever [10:50:16 CET] <atomnuker> durandal_1707: in any case at least _fix the bloody indentation_, its all over the place [10:50:32 CET] <atomnuker> the RETS need to be indented and the "add wq, rq" needs to be unindented by one [10:51:28 CET] <durandal_1707> atomnuker: post asm identation rules with example or already written asm code i should use as reference [10:51:30 CET] <atomnuker> I think the rfc said only 5 and 6 were different [10:52:59 CET] <atomnuker> durandal_1707: textbook example: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/x86/diracdsp.asm#L2… [10:53:38 CET] <atomnuker> I don't mind if internal loops get indented by one, as long as after a loop things get correctly... unindented [10:54:34 CET] <atomnuker> (I do mind about a jump being indented though, it should be indented to the same level as stuff inside the loop) [10:58:09 CET] <atomnuker> michaelni: everything except testvector02.dec, testvector03.dec and testvector04.dec needs to get v2 [11:01:55 CET] <atomnuker> michaelni: you'll also need to patch the fate test with this: https://pars.ee/temp/opus_fate_upd.diff [11:02:05 CET] <atomnuker> and rename the new samples to testvector_v2_## [11:02:55 CET] <atomnuker> you can _remove_ 07, 09, 11 and even 01 if you want to [11:03:07 CET] <atomnuker> because those samples were never used in a fate test at all [11:04:12 CET] <atomnuker> (I added a check for 01 just now because I saw it was never used, but feel free to remove it) [11:26:56 CET] <michaelni> atomnuker, can you provide a .tar that i can just copy/move files from ? (iam too dumb to follow complex multi file rename instructions and not mess up occasionally) [11:51:57 CET] <cone-856> ffmpeg 03Rostislav Pehlivanov 07master:ce87e630fa00: opus_celt: deduplicate band quantization/dequantization function [11:51:58 CET] <cone-856> ffmpeg 03Rostislav Pehlivanov 07master:7b46add72576: opus_pvq: do not compile encoding/decoding code if the encoder/decoder is disabled [11:51:59 CET] <cone-856> ffmpeg 03Rostislav Pehlivanov 07master:e836a0b3fd69: fate-opus: update tests to use new decoder outputs [11:52:08 CET] <atomnuker> michaelni: https://pars.ee/temp/testvector05_v2.dec and https://pars.ee/temp/testvector06_v2.dec [11:52:29 CET] <atomnuker> just put them in $FATE_SAMPLES/opus and they'll work [11:52:56 CET] <atomnuker> those 2 tests alone are enough to test the new hybrid folding, so no need to update the rest, even if they're slightly different [11:53:14 CET] <atomnuker> I've patched the fate test so you only need to put them [11:54:08 CET] <atomnuker> and remove 01, 07, 09 and 11 because they're not used and they've never been used if space matters [11:54:28 CET] <atomnuker> (if space doesn't matter, do mention and I'll add them to the test) [12:17:41 CET] <michaelni> atomnuker, if i remove 01, 07, 09 and 11 then fate-opus-testvector01, fate-opus-testvector07 fate-opus-testvector09 fate-opus-testvector11 fail [12:19:02 CET] <atomnuker> damn, I guess you can't remove them because even though their results weren't checked they were still needed [12:20:18 CET] <atomnuker> what a mess, usually decoders are set in stone once the bitstream is declared stable [12:21:58 CET] <nevcairiel> yeah it is a bit unusual to re-define the decoder [12:28:41 CET] <atomnuker> michaelni: but how did you change the fate references to use the ones from the official archive rather than the previous one [12:28:53 CET] <atomnuker> (to save space by switching from f32 -> s16) [12:29:41 CET] <michaelni> atomnuker, i dont remember changng anything [12:30:21 CET] <michaelni> opus/testvector05_v2.dec opus/testvector06_v2.dec uploaded [12:31:57 CET] <michaelni> nevcairiel, mpeg4 qpel was also changed (that is spec changed to match reference implementation which broke some decoders like ours really long ago which was following the spec and not the implementation) [12:38:43 CET] <atomnuker> thanks [12:38:45 CET] <atomnuker> michaelni: https://github.com/FFmpeg/FFmpeg/commit/d228271813ab2c2a3196dcff813cee93c79… [12:47:16 CET] <atomnuker> did that unintentionally break fate by replacing files? [12:47:59 CET] <michaelni> atomnuker, i almost dont remember this commit [12:48:31 CET] <michaelni> but i doubt it broke fate because everyone would have noticed and fried me if it did [12:50:04 CET] <atomnuker> weird, going to push a commit to check the results of 01, 07, 09, and 11 soon (once I deduplicate another function) [12:50:22 CET] <atomnuker> might as well make them do something if we've got them [12:52:44 CET] <michaelni> maybe the tests where disabled and not working before this commit [12:56:09 CET] <atomnuker> seems so actually [13:03:18 CET] <nevcairiel> yeah the commit enabled the tests [13:03:23 CET] <nevcairiel> was commented out before [13:43:21 CET] <jdarnley> Ha ha ha. I was searching for a page about intel things and DuckDuckGo added me this message "Including results for intel®" [13:55:57 CET] <jdarnley> durandal_1707: there aren't byte-sized versions of all registers available on x86 ^ [13:56:52 CET] <durandal_1707> yes, how to fix this? [13:57:54 CET] <jdarnley> Not sure. [14:00:09 CET] <jdarnley> I would suggest moving r0 somewhere else, use r0b for this part and then "somewhereelse" for what r0 should be. [14:01:58 CET] <jdarnley> No, on second thoughts reverse x and v arguments to cglobal [14:05:26 CET] Action: jdarnley goes afk [14:13:57 CET] <friki_> Hi, I'm working on my first ffmpeg patch (libavformat/mxfenc.c)... and I have my first question: Is there a reason why "avio_put_str16be(pb, value)" doesn't work as expected if "value" length is 20 or more? [14:15:00 CET] <thardin> in what way doesn't it work as expected? [14:18:26 CET] <friki_> thardin: my patch here: https://paste.debian.net/999034/ [14:19:27 CET] <friki_> Take a look at "void mxf_write_track". If I remove the line with "tag->value[19] = '\0'" it stops working [14:20:08 CET] <friki_> As I've said it's my first time reading ffmpeg code, so probably I'm doing it wrong :-/ [14:20:58 CET] <thardin> uhh yeah? [14:21:08 CET] <thardin> it's nul terminated like C strings typically are [14:21:34 CET] <friki_> yap, if i remove that line there is no title tag in output file [14:21:49 CET] <friki_> avio_put_str16be return correct values each time [14:22:10 CET] <thardin> is tag->value terminated? [14:22:36 CET] <friki_> if i change "19" by "20" in this line also fails [14:22:51 CET] <friki_> 19 seems to be the limit [14:22:56 CET] <thardin> that's strange but not really what I'm after [14:23:29 CET] <thardin> what does strlen() say? [14:24:22 CET] <thardin> can't imagine AVDictionaryEntry has a 20 bytes value limit [14:25:15 CET] <friki_> strlen(tag->value) is 32 in my test [14:26:44 CET] <thardin> does avio_put_str16be() do anything strange? I recall it possible copying the string into a new buffer [14:27:12 CET] <thardin> maybe it expects wide strings and you're putting in 8-bit ones? [14:29:37 CET] <friki_> i'm using de mxf helper "mxf_write_local_tag_utf16" to transform my string (utf8?) into utf16. It just calculate the propper size and call "avio_put_str16be" [14:32:41 CET] <thardin> oh god those animations on ffmpeg.org [14:35:16 CET] <thardin> uhh avio_put_str16be() isn't implemented anywhere [14:35:46 CET] <thardin> try grep -R avio_put_str16be . in the root of the ffmpeg repo [14:35:59 CET] <thardin> or git grep if you prefetr [14:37:12 CET] <thardin> oh nm there's a macro in aviobuf [14:37:38 CET] <thardin> I'd put some debug printing in put_str16() in aviobuf.c [14:55:39 CET] <friki_> thardin: put_str16 seems to do the work. I'll keep finding the problem. thanks for the tips :-) [15:03:25 CET] <thardin> friki_: the unicode logic in libavformat looks very suspicious, so I wouldn't doubt there's bugs hidden in it [15:10:28 CET] <cone-856> ffmpeg 03Paul B Mahol 07master:5ff0d2acaef8: avfilter/x86/vf_hflip.asm: fix building on x32 [15:31:03 CET] <JEEB> x32? [15:31:09 CET] <JEEB> did someone actually try using it on x32? [15:31:23 CET] <JEEB> didn't we more or less explicitly not support x32? [15:35:03 CET] <kierank> x32 is dead [15:35:05 CET] <jdarnley> He means x86 [15:35:12 CET] <kierank> Yeab [15:35:40 CET] <JEEB> I kind of guessed that, I'm just an asshole that wants a "whoops" reaction or something along those lines :P [15:35:55 CET] <jamrial> how did that fix x86_32 anyway? it was well within the gpr limit [15:35:58 CET] <atomnuker> how would people survive without being able to mmap arbitrarily huge files nowadays [15:37:37 CET] <jdarnley> jamrial: it was trying to use a byte-sized register that doesn't exist on x86. [15:38:09 CET] <jamrial> oh right, that stupid limitation [15:38:13 CET] <jdarnley> only r0-r3 have them on x86 [15:38:30 CET] <jamrial> man, does x86_32 suck... [15:38:45 CET] <atomnuker> it rules, just don't use byte registers [15:38:56 CET] <atomnuker> oh, x86_32, yeah, it sucks [15:39:39 CET] <jdarnley> It is a little hard to copy a byte when you don't have a byte-sized register [15:40:58 CET] <atomnuker> why copy 1 byte when you can copy 4 at a time! [16:52:59 CET] <cone-856> ffmpeg 03Steven Liu 07master:d67c1dda4032: avformat/hlsenc: fix compiling error when disable-network [17:39:02 CET] <daddesio> atomnuker: i'm bored, need something new to do. I could do a SILK encoder, or add support for packet-loss concealment. [17:39:35 CET] <daddesio> only problem is I'm not 100% sure how the noise-shape quantizer works in SILK. I know about noise shaping, minimizing error in the perceptually weighted domain etc. [17:40:17 CET] <daddesio> i'm currently doing an EA MicroTalk encoder: https://github.com/daddesio/utkencode [17:42:36 CET] <daddesio> probably it's more important to at least add decoder support for PLC frames though. [17:55:39 CET] <daddesio> "Hence, a much better design (and indeed the standard practice for multi-pulse speech codecs) is to search for the positions and amplitudes of n pulses such that error is minimized in the output domain (or the perceptually weighted domain)." [17:55:42 CET] <daddesio> Fun fact: This is actually a Toeplitz (FIR-filtering) matrix equation ***with deleted columns*** (hence the matrix is no longer Toeplitz anymore). I tried finding any kind of O(n^2) algorithm for this but it still seems the most efficient solution to this equation is plain ol' Matrix Least Squares (via QR decomposition), which (in utkencode tool) I'll probably end up using ATLAS/LAPACK for. [17:58:22 CET] <daddesio> erm no... sorry, I was thinking of the reoptimization problem [17:58:34 CET] <daddesio> when you have *already decided* where you will place down the n pulses [17:59:05 CET] <daddesio> (you can decide on the pulse locations using cross-correlation of the signal against the perceptual weighting filter's impulse response) [18:00:03 CET] <daddesio> In fact, encoding EA Microtalk nicely is so hard precisely because the codec doesn't have a pre-filter/post-filter like most CELP codecs. [18:21:45 CET] <durandal_1707> michaelni: when you planned to ditch deprecated yuvj pixel formats? [18:38:24 CET] <durandal_1707> how can i force scale filter when only color range differ? [18:42:37 CET] <BtbN> Isn't there pretty much always an auto inserted scaler, even if everything matches? [18:44:23 CET] <durandal_1707> for color range it obviously isnt [19:18:40 CET] <cone-856> ffmpeg 03sfan5 07master:942eafcf08c4: libavcodec/hevc_filter: support for all skip_loop_filter levels. [19:18:49 CET] <sfan5> yay [19:22:28 CET] <kurosu> in theory, the last progress report should likely be y + ctb_size - 4*!skip, but oh well [19:23:56 CET] <kurosu> also maybe the skip derivation should have been in ff_hevc_hls_filters, and then passed [19:29:16 CET] <BtbN> Does configure have some magic to do "enabled_any nvenc nvdec cuvid cuda && ..."? [19:29:34 CET] <BtbN> oh, it actually does [19:29:41 CET] <BtbN> called... enabled_any [19:31:38 CET] <BtbN> hm, that's not the right way to do it anyway [19:38:00 CET] <BtbN> Oh great, the nvidia compat headers include ffmpeg headers [19:38:24 CET] <BtbN> Guess the loader-header will have to stay in-tree [19:41:13 CET] <flydev> Hi guys, the last ffmpeg compile guide for Ubuntu 16 is broken [19:41:20 CET] <BtbN> fix it [19:42:31 CET] <flydev> Nah, tried, it's screwed up badly [19:42:54 CET] <flydev> libx265.so.147: cannot open shared object file: No such file or directory [19:43:56 CET] <flydev> Already have dozens of Ubuntu 14 hosts with older version compiling and running fine, this one also seems to compile everything fine, but it does not run at all [19:44:38 CET] <flydev> And can't really figure out why x265 lib is missing when x265 compiles fine [19:45:00 CET] <nevcairiel> you want #ffmpeg, this channel is not for user help [19:47:02 CET] <cone-856> ffmpeg 03James Almer 07master:1b324700e3a1: checkasm/vf_threshold: fix mixed code and declarations [19:47:03 CET] <cone-856> ffmpeg 03James Almer 07master:bfd7f07b650b: fate/checkasm: add missing target for vf_threshold test [19:47:04 CET] <cone-856> ffmpeg 03James Almer 07master:cc2ba526d414: x86/vf_threshold: make threshold8 functions work on x86_32 [21:39:15 CET] <cone-856> ffmpeg 03Paul B Mahol 07master:312b00de8f8b: avfilter/vf_convolution: add 7x7 filter [00:00:00 CET] --- Tue Dec 5 2017

1 0

ffmpeg.log.20171204
by burek 05 Dec '17

05 Dec '17

[00:00:12 CET] <JEEB> *-profile:v baseline [01:12:18 CET] <kinkinkijkin> does ffmpeg no longer provide libav.so.57 ? [01:12:48 CET] <JEEB> API version got bumped [01:12:56 CET] <kinkinkijkin> hmmm [01:13:01 CET] <JEEB> also it's libavcodec most likely :P [01:13:13 CET] <JEEB> no idea what libav.so is :P [01:13:14 CET] <kinkinkijkin> ah yes I forgot the codec part [01:13:38 CET] <kinkinkijkin> anyways obs still builds against .57, regardless of if I build manually, so I've been having some issues [01:13:48 CET] <kinkinkijkin> know if the arch packages is updated to the api bump yet? [01:13:59 CET] <kinkinkijkin> might go back to the non-git version but I noticed the version bumped [01:14:27 CET] <JEEB> any project building against FFmpeg should be building against the non-versioned lib [01:14:36 CET] <JEEB> and then that would be symlinked to some version during build time [01:14:50 CET] <JEEB> so if it was built with a newer git version like you say it wouldn't matter [01:14:55 CET] <kinkinkijkin> hmmm [01:14:57 CET] <kinkinkijkin> strange issue then [01:15:16 CET] <JEEB> if the issue is that you're taking in random binaries of OBS then that's a problem of course [01:15:19 CET] <JEEB> :P [01:15:29 CET] <kinkinkijkin> no, I'm building my own [01:16:06 CET] <kinkinkijkin> I've rebuilt ffmpeg manually, would you really think I'd be dumb enough to take in random binaries off the web? [01:16:24 CET] <JEEB> well if things don't work that's the first possibility [01:16:26 CET] <JEEB> and not saying random [01:16:33 CET] <JEEB> just that it might be a distro package or whatever [01:16:40 CET] <kinkinkijkin> hmm [01:16:57 CET] <kinkinkijkin> ABS package didn't work, neither did the git aur package, for rebuilding obs [01:59:09 CET] <rajkosto> JEEB, do you know how to explicitly use dxva2/d3d11va to decode h264 ? it has something to do with setting the appropriate pixfmt [02:03:40 CET] <jkqxz> rajkosto: Look at the hw_decode example. [02:04:29 CET] <rajkosto> oooh when did this get made [02:10:33 CET] <rajkosto> this is too recent, not available in my version [02:13:14 CET] <jkqxz> Upgrade? [02:13:31 CET] <jkqxz> Making it work in older versions is ... not fun. [02:13:42 CET] <rajkosto> cant, the null packet flush is not working in newer versions [02:19:55 CET] <JEEB> :D [02:20:13 CET] <JEEB> it really sounds like the simplest way to go about is to implement the "don't reorder" feature in the h264 decoder :P [02:20:25 CET] <rajkosto> i want to try dxva why you hate [02:20:32 CET] <JEEB> I don't [02:20:43 CET] <JEEB> I have a commit in d3d11va for christ's sake [02:20:43 CET] <rajkosto> its not "dont reorder", its "dynamically adjust how many frames to delay output" [02:20:43 CET] <JEEB> :D [02:21:18 CET] <JEEB> hmm, I wonder how complex the rule set for that would be [02:21:28 CET] <JEEB> and it would still not fix your issue with the other API? [02:21:35 CET] <JEEB> unless you give it a good kick and change it [02:21:45 CET] <rajkosto> how change binary compatibility [02:23:29 CET] <JEEB> what on earth are you thinking about :P [02:24:02 CET] <rajkosto> ill try the hw_decode sample with new version, which one should i clone [02:24:47 CET] <JEEB> http://fate.ffmpeg.org/ [02:24:50 CET] <JEEB> check your OS/compiler [02:25:01 CET] <JEEB> if it passes as usual, just use latest HEAD [02:25:33 CET] <rajkosto> nice non working windows [02:25:43 CET] <JEEB> ? [02:26:08 CET] <JEEB> both mingw boxes from less than 2 h ago build [02:26:10 CET] <rajkosto> all the msvc are error compiling [02:26:25 CET] <JEEB> oh, so that I guess what jamrial was fixing 8) [02:26:32 CET] <JEEB> he had some patches on the ML for that [02:26:59 CET] <rajkosto> this why i dont change versions unless absolutely necessary [02:27:09 CET] <JEEB> this is pretty rare :P [02:27:14 CET] <JEEB> and you always have FATE [02:27:25 CET] <JEEB> any real breakage gets found out rather quickly [02:27:48 CET] <JEEB> I mean, build or test breaking stuff [02:27:54 CET] <rajkosto> how do i find the last one that works [02:28:39 CET] <jkqxz> Are you actually using MSVC? [02:28:43 CET] <rajkosto> of course [02:29:05 CET] <JEEB> 3701d49 was the one that broke it [02:29:08 CET] <JEEB> so the one before that [02:30:15 CET] <JEEB> I guess abf669479c0098ab5eb184a167e57a70aabb942b ? [02:30:30 CET] <JEEB> which is before the atomic removals [02:31:22 CET] <rajkosto> should i just use 3.4 ? [02:31:59 CET] <JEEB> you can also do that if you want, do note that things can or not be in any better state :P [02:32:11 CET] <JEEB> things are after all actively fixed in master, but not many people look at releases [02:32:17 CET] <JEEB> just so you know [02:32:22 CET] <rajkosto> releases should at least build on all compilers [02:32:35 CET] <JEEB> """all""" [02:32:43 CET] <JEEB> that is a rather wide range [02:34:31 CET] <JEEB> and any breakage tested by FATE generally gets fixed quickly as I said - and fixes accidentally breaking compilation on relase branches can happen just as well, although less likely in general because of less changes in general. that said I'm not sure if anyone looks too much at FATE when branching off. not that I know the release procedure [03:30:39 CET] <rajkosto> must i override get_format to use hw decode ? seems that just setting pix_fmt doesnt do it [03:54:25 CET] <rajkosto> seems like it, and now im getting no frames out [10:36:52 CET] <kiranbsravi> "java(1128,0x700003430000) malloc: *** error for object 0x7fafa4068a00: pointer being freed was not allocated" error message is thrown upon calling av_write_trailer() in libavformat library while closing the file. I am using libavformat to mux two audio and video streams into a webm file. [10:40:56 CET] <Fig1024> seems like invalid pointer, maybe some modules were freed prior to your call [11:01:43 CET] <kiranbsravi> but i haven't freed any modules before calling av_write_trailer() [11:05:51 CET] <Fig1024> that pointer value is too large to be real, so it's definitely invalid. That memory was overwritten by something, which typically happens when pointer references freed memory. Or when some buffer overrun type of bug happens [14:28:22 CET] <rajkosto> JEEB, seems like its nothing to do with b-frames, there's always 2-frame latency in h264dec somehow [14:28:54 CET] <JEEB> have you checked the SPS? [14:29:07 CET] <JEEB> and/or added debug logging to h264dec [14:29:19 CET] <rajkosto> whats the ffprobe for that on annex-b file [14:29:45 CET] <JEEB> I remember someone made a bsf for this stuff with nice logging but I don't remember how it's usable [14:30:03 CET] <JEEB> I think it might be simpler to do the av_log addition to h264dec [14:30:33 CET] <JEEB> so you can change the spots where teh delay would be set in the decoder to add av_log logging [14:30:56 CET] <JEEB> anyways, $dayjob [14:31:47 CET] <bencoh> rajkosto: how many threads do you have? [14:31:54 CET] <bencoh> decoding threads that is [14:32:21 CET] <rajkosto> i even tried setting thread_count = 1, thread_type = 0 (or SLICE), delay = 0 [14:33:14 CET] <bencoh> I (not so) vaguely remember avcdec adding a latency of one frame per thread [14:33:28 CET] <rajkosto> it should, if you use FRAME threading [14:33:33 CET] <rajkosto> SLICE/no threading shouldnt [14:33:48 CET] <bencoh> ah, missed the slice, mybad [14:35:50 CET] <rajkosto> ctx->delay never changes from my set 0 [14:35:53 CET] <rajkosto> yet the delay is 2 [14:39:50 CET] <dradakovic_> Has anyone ever tried to output FFMPEG streams to DCM or monitored them with a probe? I input the HTTP radio and output it as UDP multicast. When i monitor this stream on probe i can see a massive IAT (Inter Arrival Time of Frames). I would like to lower that time so that DCM has no problems accepting my multicast. [14:40:07 CET] <dradakovic_> I hope someone has any clue what i mean :) [14:40:33 CET] <dradakovic_> I do that for a HTTP radio [14:44:02 CET] <rajkosto> bencoh, on the first avcodec_receive_frame it doesnt even try to decode anything, it fails after get_pkt returns a negative value [14:46:56 CET] <rajkosto> ff_bsf_get_packet returns EAGAIN, pretty sure i gave it plenty of nals already [14:47:33 CET] <rajkosto> yep it has 190939 bytes yet its not enough [14:49:37 CET] <bencoh> "plenty of nals" you do feed it with complete encoded frames, right? [14:49:43 CET] <rajkosto> yep [14:50:18 CET] <rajkosto> i eat nals until the picture_num is different in the NAL or whatever, thats a complete frame [14:50:26 CET] <rajkosto> then i send those in one go as an avpacket [14:53:17 CET] <rajkosto> theyre in annex-b, ofc [15:01:36 CET] <rajkosto> ok so its because inside avcodec_send_packet it consumes it immediately if (!avci->buffer_frame->buf[0]) [15:19:59 CET] <rajkosto> i do get here on the first frame av_log(h->avctx, AV_LOG_DEBUG, "no picture %s\n", out_of_order ? "ooo" : ""); [15:28:29 CET] <Bear10> Has anyone used the nginx-rtmp-module and managed to create a dynamic push endpoint to restream to a desired rtmp? [15:28:47 CET] <rajkosto> yes [15:29:30 CET] <Bear10> rajkosto: how did you go about it? since the on_push redirect doesn't support domains and on the server config level I'm unsure how or if it's even possible to introduce dynamic push directives [15:32:15 CET] <rajkosto> push rtmp://targetserver:1935/targetappname live=1 'flashVer=Nginx pushin to ya'; [15:34:22 CET] <Bear10_> rajkosto: ah ok that's not the same thing i was looking for, it's more like "push $somVar", so i've tried you're approach as well like rtmp://localhost:1935/myapp and then in the myapp configuration having a on_publish do a callback and do a 301 or 302 redirect to facebook for example, but per the documentation it doesn't support hostnames just ips [15:34:26 CET] <Bear10_> so I have no idea how to resolve that bit [15:34:49 CET] <rajkosto> you never said the target server needs to be dynamic, no clue then [15:35:27 CET] <Bear10> thanks for the help, maybe someone else knows :) [15:35:47 CET] <rajkosto> you can always hack it with exec [15:35:53 CET] <rajkosto> and just spawn a ffmpeg [15:38:19 CET] <Bear10> yeah i tried with exec as well but we ran into the same issue where i couldn't put the dynamic endpoint in the config, so i'm thinking i need to do a custom script that launches the ffmpeg in it [15:38:38 CET] <Bear10> but hey as long as i'm not the onlyone thinking it, means it's probably the easiest approach without modifying modules [15:38:55 CET] <rajkosto> its better to not look into the code of nginx-rtmp [15:39:10 CET] <Bear10> hahaha [15:39:54 CET] <Bear10> thanks rajkosto, gotta run to the vet now, cat's sick but if someone is around please feel free to drop some pointers if there's another solution [15:40:12 CET] <rajkosto> you realise nginx-rtmp has nothing to do with ffmpeg yea ? [15:40:30 CET] <Bear10> yeah but it was recommended to me in here, and wasn't sure where else to ask [15:46:50 CET] <dradakovic_> Guys how much would you set -muxrate if your output was libmp3lame with 256kb bitrate? [15:48:38 CET] <BtbN> I wouldn't set it at all? [15:52:47 CET] <dradakovic_> Ok. When i set it, it fixed my graphs on the probe i am monitoring. But in the logs i am getting dts < pcr, TS is invalid [15:57:04 CET] <DHE> that's an mpegts (format) option, not an MP3 (codec) option [15:57:43 CET] <DHE> if you're getting that error with a -muxrate set, it means it's probably too low a setting [15:57:57 CET] <dradakovic_> Ok. But i am indeed streaming output on mpegts [15:58:11 CET] <dradakovic_> so input is http, converting it to mp3 and streaming it to mpegts [15:58:20 CET] <dradakovic_> I w ill try a higher number [15:59:06 CET] <DHE> mpegts has rather high overhead. I would start with 10% on top of the audio bitrate and see how that goes [15:59:14 CET] <DHE> I'm assuming no video here [15:59:32 CET] <dradakovic_> you assume right. There is no video [16:00:02 CET] <dradakovic_> That means if my audio bitrate is 256k, you would start with 25,6k muxrate? [16:00:10 CET] <TheRock> "No codec could be found for 'vc1'" [16:00:15 CET] <TheRock> Can you tell me which decoder is required? [16:00:24 CET] <dradakovic_> sorry missunderstood. I know what you mean [16:00:31 CET] <TheRock> --enable-decoder=..vc1? [16:01:38 CET] <JEEB> have a separate ffmpeg.c around to which you can throw `./ffmpeg -decoders |grep -i "vc1"` [16:01:43 CET] <JEEB> so you don't have to keep asking the channel [16:01:44 CET] <JEEB> :P [16:02:04 CET] <TheRock> I have sepcified vc1 [16:02:07 CET] <TheRock> but it doesn't work [16:02:10 CET] <TheRock> that's why i ask [16:02:28 CET] <JEEB> do you have the parsers etc also for it if you need to demux it? [16:03:00 CET] <TheRock> yes i added vc1 in --enable-parser and --enable-demuxer [16:11:04 CET] <DHE> <dradakovic_> That means if my audio bitrate is 256k, you would start with 25,6k muxrate? # no, muxrate = 256k * 1.1 [16:11:08 CET] <DHE> that working for you? [17:23:42 CET] <alexpigment> any idea what's keeping VCE encoder integration from happening? [17:25:08 CET] <alexpigment> it looks like there was an ongoing thread on the mailing list, but the last message is from october 31 [17:25:40 CET] <Cracki> does it work? [17:29:37 CET] <alexpigment> not sure. i've tried building ffmpeg with the patch on the mailing list, but I couldn't find a vce/amf encoder in the resultant build [17:29:44 CET] <alexpigment> it's possible I did something wrong though [17:30:52 CET] <alexpigment> looking at the mailing list again, it looks like there's some sort of discussion about the lack of an AMD header, so the encoder is off in a default build [17:30:59 CET] <alexpigment> that's a bit over my head [17:35:07 CET] <Cracki> amd should just throw its people at it [17:35:47 CET] <Cracki> I'd very much like to see ffmpeg support recent hw encode of amd processors [17:36:17 CET] <Cracki> (wait, gpus, right? I had the wikipedia open just minutes ago) [17:36:32 CET] <alexpigment> gpus, yes [17:36:50 CET] <alexpigment> although a decent amount of AMD's CPUs have GPUs built in [17:36:56 CET] <Cracki> so it's similar to nvidia's nvenc, eh? [17:36:59 CET] <alexpigment> right [17:37:24 CET] <jkqxz> alexpigment: Install headers from <https://github.com/GPUOpen-LibrariesAndSDKs/AMF/tree/master/amf/public/incl…> in an AMF directory somewhere in the standard include path. Run configure (it's autodetected). [17:37:26 CET] <Cracki> I like hw encode support :) my 2012 desktop has none (xeon e3 v1, gtx 560) [17:37:31 CET] <alexpigment> and i don't really have a horse in the race, it's just important that for any modern system (within reason), there should be a hardware encoder available [17:37:51 CET] <alexpigment> jkqxz: thank you very much, i'll try that out today [17:38:41 CET] <jkqxz> (Hopefully AMD will make the header installation a bit nicer.) [17:38:59 CET] <alexpigment> i'm still reading through this thread (which I didn't see until today) about the AMD headers [17:39:24 CET] <alexpigment> i'm not sure (yet) why anyone would want to leave out headers for AMD, or to remove headers for Nvidia [17:39:37 CET] <jkqxz> It's very silly. Including the AMD header is absurd because there is a sensible upstream. [17:39:41 CET] <alexpigment> this seems like a weird absolutist position that really only makes it annoying for the end user [17:40:12 CET] <alexpigment> jkqxz: do you mind explaining that in layman's terms? [17:41:30 CET] <jkqxz> Why would anyone want headers to be included? It makes all maintenance harder - you can't build with different versions, if there is ever an incompatible change then you have to choose one side or the other, distributions can't fix the version to match everything else in them. [17:42:03 CET] <alexpigment> "can't build with different versions" = ? [17:42:07 CET] <alexpigment> different versions of what? [17:42:37 CET] <jkqxz> The headers or driver. If bundled headers were updated, the user is probably required to update the driver as well. [17:43:07 CET] <alexpigment> jkqxz: with hardware encoding, updating drivers has kind of been the norm for quite a while [17:43:19 CET] <jkqxz> This is exactly what you don't want having done proper testing of a driver for your setup. [17:43:31 CET] <jkqxz> Only for Nvidia, which forces it on everyone. [17:43:32 CET] <alexpigment> at any rate, I really appreciate that I didn't have to do anything out of the way to build with Nvidia hardware acceleration [17:44:03 CET] <alexpigment> what does nvidia force? [17:44:07 CET] <jkqxz> Would you like the libx264 headers to be included as well? [17:44:17 CET] <jkqxz> That would be "more convenient" too, wouldn't it? [17:44:58 CET] <alexpigment> honestly, i'll fully admit ignorance on all of this. I don't know what a header does or doesn't do, and I didn't know libx264 headers weren't included [17:45:07 CET] <alexpigment> i just know it's very easy to build with x264 [17:45:56 CET] <jkqxz> Because the headers are open and included by all distributions. AMD headers are open, if they package them properly then it will be easy to have them everywhere. [17:52:14 CET] <Hinton> Hello, can i get help here for ffmpeg? [17:55:39 CET] <alexpigment> Hinton: generally, you just come in and ask a question [17:55:56 CET] <Hinton> ah okay [17:56:28 CET] <Hinton> i have found ffmpeg while finding a solution to play audible books on my xubuntu [17:57:00 CET] <Hinton> i can play them with the proper key (aka. 4bytes of security), but if i convert them, they are silent [17:57:05 CET] <Hinton> any idea why? [17:58:01 CET] <Hinton> ffmpeg -loglevel error -stats -activation_bytes "${auth_code}" -i "${path}" -vn -vol 256 was the command [18:00:47 CET] <alexpigment> personally, I have no clue. I assume that command works fine on other non-audiobook sources, right? [18:01:35 CET] <alexpigment> Anyway, this gets into a weird territory re: DRM/copyright [18:01:49 CET] <alexpigment> but ultimately, if you can play something, you can record it [18:04:05 CET] <Hinton> oh my god [18:04:10 CET] <Hinton> that was sooo stupid [18:05:11 CET] <Hinton> it converts just right, it was muted. i've tested it on two different players, and vlc was set to a different sound output, which was not turnet on [18:05:17 CET] <Hinton> *turned [18:05:34 CET] <alexpigment> well there you go :) [18:06:18 CET] <alexpigment> if it makes you feel any better, I kept trying to figure out why certain videos were quieter or louder in Windows Media Player. turns out there are all this Dolby Digital specific settings that I never knew about [18:07:01 CET] <Hinton> yeah :D its ALWAYS the user ;) but thanks nonetheless :D it was your tip with the non encrypted file, which made me realize that maybe, just maybe some settings were wrong ^^ [18:16:56 CET] <rajkosto> the reference decoder is able to give me the frames immediately, no 2 frame delay like ffmpeg does [18:17:44 CET] <rajkosto> and they are in order unlike old ffmpeg with null packets [18:19:33 CET] <alexpigment> Hinton: no worries. glad you got it figured it out [18:23:39 CET] <kinkinkijkin> trying to figure out how to pipe to ffmpeg in C# using a really obscure audio backend [19:10:47 CET] <TheRock> Is .wmv basedo n h263? [19:11:49 CET] <alexpigment> wmv is several different codecs [19:12:00 CET] <alexpigment> wmv7 and 8 are based on h263 though [19:12:02 CET] <TheRock> hm, the problem is [19:12:06 CET] <TheRock> i build ffmpeg from SRC [19:12:08 CET] <alexpigment> wmv9 and vc-1 aren't [19:12:21 CET] <TheRock> and i'd like to know what i must specify for wmv series [19:12:28 CET] <TheRock> i have now VC1 in demuxer, decoder, parser [19:12:40 CET] <TheRock> but the other wmv can't be played, one wmv works [19:12:42 CET] <TheRock> though without sound [19:12:48 CET] <sfan5> probably helpful: https://en.wikipedia.org/wiki/Windows_Media_Video#Versions [19:13:38 CET] <alexpigment> TheRock: look at ffmpeg -codecs [19:14:14 CET] <alexpigment> look for wmv1, wmv2, and wmv3 [19:14:25 CET] <TheRock> i see, that's more helpful [19:14:31 CET] <alexpigment> i realize it's confusing, but wmv1 = windows media video 7 [19:14:37 CET] <alexpigment> wmv2 = windows media video 8 [19:14:43 CET] <alexpigment> wmv3 = windows media video 9 [19:14:51 CET] <TheRock> sounds like it wmv sucks [19:15:05 CET] <alexpigment> eh, wmv9/vc-1 was a pretty good format [19:15:17 CET] <alexpigment> it just doesn't have the broadest support [19:16:14 CET] <alexpigment> up until windows started integrating H.264 support into Windows Media Player, WMV9/VC-1 was actually a very good option for a format that would play with certainty and have a good compression ratio [19:16:26 CET] <TheRock> I see [19:16:41 CET] <TheRock> but i remember that i had to install some codecs on windows 10 [19:16:47 CET] <TheRock> to play an mp4 [19:16:58 CET] <TheRock> K-Lite codec pack [19:17:09 CET] <alexpigment> that had to have been unrelated to H.264 [19:17:32 CET] <TheRock> isn't mp4 h264? [19:17:33 CET] <alexpigment> also, K-Like is a good way to screw up the codec associations on your system. i'd highly recommend against installing codec packs [19:17:41 CET] <alexpigment> TheRock: not always [19:18:05 CET] <alexpigment> but Windows 10 should have had out-of-the-box support for any of the video codecs within a standard MPEG-4 file [19:18:16 CET] <alexpigment> i'd guess that either it was an audio format or something else [19:18:51 CET] <alexpigment> what Windows 10 doesn't have is a built-in MPEG-2 codec. those cheap bastards dropped support in Windows 8, thereby killing native DVD support for a lot of people [19:19:49 CET] <TheRock> lol [19:19:59 CET] <TheRock> that's when you would need k-lite codec pack then? [19:20:34 CET] <alexpigment> i can't think of a scenario where I would ever let K-lite be installed on my system [19:20:54 CET] <alexpigment> but still, there were other ways around it, especially if you have the Pro version of Windows [19:21:53 CET] <alexpigment> of course, there are players with built-in codecs that are another option, but the hardware accelerated playback, deinterlacing, and upscaling of Windows Media Player is hard to beat [19:22:28 CET] <TheRock> yeah, it's optimized for windows [19:22:30 CET] <alexpigment> anyway, I use Windows 7, so I don't have to deal with any of this first-hand [19:24:02 CET] <TheRock> there are so many codecs [19:24:11 CET] <TheRock> the best is probably to built all inside the app [19:24:22 CET] <TheRock> but the size of my app grows pretty hard [19:24:38 CET] <TheRock> Now, i'm at 5mb after all codecs 15-20 [19:26:52 CET] <alexpigment> TheRock - yeah, there are definitely a lot of codecs out there [19:27:14 CET] <alexpigment> but for video codecs, I think you could support the vast majority with only 6-8 codecs [19:28:46 CET] <alexpigment> and right as I said that, I started counting them in my head, and it's probably more than 6-8 :) [19:34:08 CET] <TheRock> ./configure --disable-everything --extra-version=QtAV --disable-debug --enable-static --disable-shared --enable-runtime-cpudetect --toolchain=msvc --extra-ldexeflags='-SUBSYSTEM:CONSOLE,5.01' --enable-avresample enable-decoder= wavpack,wmav1,wmav2,wmv1,wmv2,wmv3,mpeg1video,mpeg2video,mpeg4,avi,wma,ogg,wmv,vp8,vp9,opus,vorbis,vc1,mpegvideo,flv,mp3,aac,h264,mpeg2video,mpeg4,asf,swf,mov,wav [19:34:08 CET] <TheRock> --enable-demuxer=wavpack,wmav1,wmav2,wmv1,wmv2,wmv3,mpeg1video,mpeg2video,mpeg4,wmv,ogg,vc1,m4v,flv,mp3,aac,avi,h264,matroska,pcm_s16le,mov,m4v,rawvideo,wav,mpegvideo,wma,asf,swf,vp8,vp9 --enable-parser=wavpack,wmav1,wmav2,wmv1,wmv2,wmv3,mpeg1video,mpeg2video,mpeg4,ogg,wmv,flv,vc1,vp8,vp9,vorbis,opus,aac,h264,mpeg4video,mpegaudio,mpegvideo,wma,asf,swf,avi,mov,wav --disable-programs --enable-p [19:34:08 CET] <TheRock> rotocol=file [19:34:19 CET] <TheRock> I hope this will include now all popular [19:34:27 CET] <TheRock> i added it for security to parser, demuxer as well [19:34:35 CET] <TheRock> invalid commands should be ignored [19:35:54 CET] <alexpigment> well, i can understand explicitly limiting it out, but H.265/HEVC is becoming pretty common [19:36:15 CET] <TheRock> Is h265 supported? [19:36:19 CET] <sfan5> >wavpack [19:36:22 CET] <sfan5> people use that? [19:36:30 CET] <alexpigment> then there's something like DV, which admittedly has fallen out of use, but was a huge standard for a long time [19:36:33 CET] <TheRock> i don't know, sounds like its used for .wav files ? [19:36:51 CET] <sfan5> .wav files usually contain pcm_s16le [19:36:57 CET] <sfan5> wavpack is yet another codec to compress those [19:36:59 CET] <alexpigment> yes, h265 is supported [19:37:23 CET] <TheRock> ah, ok. Gonna remove it then [19:38:31 CET] <TheRock> alexpigment: is HEVC a different codec? [19:38:34 CET] <TheRock> or is it enough to add h265 [19:38:43 CET] <alexpigment> it's the same codec [19:38:46 CET] <TheRock> --enable-decoder=h265 [19:39:18 CET] <alexpigment> all modern video formats have two names, just to mess with people ;) [19:39:29 CET] <alexpigment> at least two [19:39:53 CET] <alexpigment> AVC = H.264 = MPEG-4 Part 10 [19:40:15 CET] <alexpigment> HEVC = H.265 = MPEG-H Part 2 [19:40:32 CET] <alexpigment> admittedly, i've never seen anyone say MPEG-H Part 2 [19:42:20 CET] <JEEB> I have, but it's as little used as MPEG-4 Part 10 ;) [19:42:28 CET] <JEEB> AVC/HEVC are just simpler to write [19:43:12 CET] <alexpigment> well, with the former, at least H.264 was more commonly used and recognized by the masses (as much as the masses will ever recognize a codec) [19:43:29 CET] <alexpigment> with H.265 / HEVC, I still don't know what to call it to make the most people understand it [19:43:45 CET] <alexpigment> it *feels* like HEVC is more prevalent [19:44:06 CET] <rajkosto> just use AV1 instead :P [19:44:23 CET] <alexpigment> rajkosto: buy me a card that has hardware support for it, and it's a deal [19:44:33 CET] <alexpigment> (and also buy a phone that has support for it. thanks ;)) [19:44:41 CET] <kepstin> the name 'av1' is annoying too, because 'av' sounds like 'audio/visual', but it's only a video codec :) [19:44:48 CET] <alexpigment> oh and lastly, i'm going to need a tv with native support [19:45:35 CET] <kepstin> (the 'a' is actually supposed to be for 'AOMedia' - 'Alliance for Open Media') [19:45:49 CET] <TheRock> i added h265 [19:45:53 CET] <TheRock> (ffmpeg 3.4 src) [19:46:03 CET] <TheRock> but it doesn't appear in the configuration overview [19:46:14 CET] <flydev> Hi guys, the last ffmpeg compile guide for Ubuntu 16 is broken [19:46:14 CET] <flydev> libx265.so.147: cannot open shared object file: No such file or directory [19:46:22 CET] <TheRock> is there --enable-gpl required? [19:46:33 CET] <TheRock> I just use it for decoding [19:46:34 CET] <alexpigment> TheRock: most likely [19:46:40 CET] <flydev> Already have dozens of Ubuntu 14 hosts with older version compiling and running fine, this one also seems to compile everything fine, but it does not run at all [19:46:40 CET] <flydev> And can't really figure out why x265 lib is missing when x265 compiles fine [19:46:42 CET] <sfan5> gpl is required for decoders? o.O [19:46:47 CET] <alexpigment> as I said earlier, i can understand why someone wouldn't include it [19:46:48 CET] <TheRock> usually not [19:46:56 CET] <TheRock> but h265 is not recgonized somehow [19:47:08 CET] <TheRock> --enable-deocders=h265,h264,h263 [19:47:11 CET] <kepstin> the decoder's called hevc, not h265 [19:47:16 CET] <jkqxz> flydev: You forgot to run ldconfig after installing a new version? [19:47:19 CET] <TheRock> oh, ok [19:47:30 CET] <TheRock> because the previous version was called just 'h264' [19:47:38 CET] <rajkosto> deocders :P [19:48:05 CET] <TheRock> yah, just typed that :P. its correct in my build [19:48:45 CET] <flydev> jkqxz this is on a fresh install of ubuntu 16 [19:48:57 CET] <flydev> following this guide: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [19:50:00 CET] <jkqxz> Well, the install is definitely polluted somehow if it can't find a shared library like that. [19:50:43 CET] <jkqxz> Since that message implies it was available at link time but not at run time. [19:50:56 CET] <kepstin> flydev: did you build your own libx265 or just use the distro one (libx265-dev)? [19:51:19 CET] <jkqxz> (Not having run ldconfig to link SONAMEs being the most obvious way to achieve that.) [19:51:24 CET] <flydev> or the doc is not reflected to apply for vanilla installs? tried 3 machines, and few VPS'es, tried building my own and the distro one [19:51:30 CET] <kepstin> this could happen if you built it yourself and had the distro one installed at the same time, and have linking errors [19:52:42 CET] <flydev> i have the distro one removed by apt-get remove --purge lib265-dev and recompiling my own - no luck [19:53:56 CET] <kepstin> that removes the dev headers, did you also remove the lib? should be libx265-79 on xenial [19:54:24 CET] <flydev> how can I get rid of the whole lib? via the commandline that is [19:54:33 CET] <kepstin> apt-get remove libx265-79 [19:55:43 CET] <kepstin> but if you have other stuff depending on it, that'll remove a lot of things [19:55:51 CET] <TheRock> Looks like the wmv* codecs add hw accelerators to my build. Could i use --disable-hwaccels to use only software rendering? [19:56:05 CET] <TheRock> or are they mandatory [19:56:25 CET] <kepstin> TheRock: unless you explicitly use the hw decoders, ffmpeg will decode in software by default. But feel free to build without them to save space [19:57:08 CET] <flydev> Package 'libx265-79' is not installed, so not removed .... huh, something is very wrong here...... okay, doing reinstall (again), atleast it's a VPS and it will be quick [19:57:44 CET] <kepstin> ok, so something's going wrong manually installing libx265 then :/ [19:58:05 CET] <kepstin> it would be helpful to see more context of the failing link command [19:59:44 CET] <kepstin> i wonder if the issue is that libx265 has changed how they install stuff at some point, so their pkg-config file is broken or something. [19:59:52 CET] <flydev> yeah, it gets stuck at [ 86%] Building CXX object common/CMakeFiles/common.dir/deblock.cpp.o and failing to allocate memory.... okay, trying with 8 GB RAM.. [20:01:42 CET] <flydev> okay, new take - 16 vCPU, 8 GB RAM, this time i'm not joking, fingers crossed [20:02:01 CET] <flydev> and doing makes with -j16 if that's of any impotance [20:02:52 CET] <kepstin> well, reducing the -j will make it use less ram... [20:04:02 CET] <flydev> I don't have problems with that, it's just that last builds ran and compiled fine with Ubuntu 14 on 2GB RAM [20:04:19 CET] <flydev> okay, this time no RAM errors, it's compiling the ffmpeg [20:04:21 CET] <kepstin> newer gcc versions use more ram [20:04:31 CET] <kepstin> flydev: once you have libx265 installed, can you pastbin the output of these two commands: [20:04:56 CET] <kepstin> cat ~/ffmpeg_build/lib/pkgconfig/x265.pc ; ls -l ~/ffmpeg_build/lib/libx265* [20:06:16 CET] <flydev> https://pastebin.com/LtZHZ8GT [20:06:40 CET] <kepstin> that all looks good [20:06:48 CET] <flydev> nah, still broken [20:06:57 CET] <flydev> https://pastebin.com/YAUK7MwE [20:07:48 CET] <kepstin> ok, that shouldn't be happening, the ffmpeg commands on that page are supposed to build a static ffmpeg [20:07:51 CET] <flydev> stuff like : command not found scare me a lot, that's from the compile log, shall i go back to vanilla again? [20:07:58 CET] <kepstin> it shouldn't be trying to load the .so at all [20:08:10 CET] <kepstin> are you sure you copied the 'configure' line correctly? [20:08:57 CET] <flydev> yes, it's a copy/paste from the https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu page, nothing is changed [20:09:58 CET] <kepstin> that makes no sense; everything's set up to do the static build correctly there :/ [20:10:27 CET] <furq> have you run make clean on ffmpeg after removing the apt libx265 [20:10:53 CET] <flydev> only thing I do add is --enable-openssl like so: https://pastebin.com/Wd7Df5nn [20:11:46 CET] <flydev> and I have the libssl-dev and openssl installed [20:11:56 CET] <flydev> okay, will try make clean, just in case [20:13:14 CET] <flydev> did it, compiling [20:15:43 CET] <flydev> still broken [20:20:26 CET] <kepstin> huh, interesting. this set of commands breaks when building x264 on newer ubuntu versions (17.10) because th compiler enables PIC by default there. [20:20:45 CET] <kepstin> i think? or something weird. [20:21:14 CET] <kepstin> owell, on 17.10 you get a new enough ffmpeg that there's no much reason to bother building one unless you want something bleeding edge or nonfree [20:21:52 CET] <flydev> nonfree and openssl ;) [20:22:19 CET] <flydev> and it must be on a LTS OS [20:25:25 CET] <kepstin> alright, i see the problem. at some point the x265 cmake must have changed the option used to disable the shared lib build [20:25:38 CET] <kepstin> it installed the shared lib even though that was supposed to be turned off [20:26:07 CET] <kepstin> you can probably work around this by just doing `rm ~/ffmpeg_build/lib/libx265.so*` before building ffmpeg [20:31:44 CET] <flydev> did this, and a make clean in ffmpeg [20:34:30 CET] <kepstin> huh, weird, it worked for me; only built & installed the static lib like it was supposed to. [20:35:27 CET] <kepstin> i dunno what went wrong for you with the libx265 build :/ [20:36:02 CET] <kepstin> oh, the timestamps on your 'ls' show the story [20:36:42 CET] <kepstin> looks like you built it on dec 1, something went wrong (copy/paste error on cmake command maybe?) then rebuilt it correctly on dec 4 but the old lib was left there [20:36:59 CET] <flydev> running compile after make clean on ffmpeg and rm ~/ffmpeg_build/lib/libx265.so and because I did a reboot it's with 1 CPU core doing the compile which will take a while [20:37:40 CET] <kepstin> starting again on a fresh machine would have fixed it, or deleting the bin and ffmpeg_build directories :/ [20:38:40 CET] <flydev> https://pastebin.com/Z8bDBKQW [20:46:03 CET] <flydev> and it's a success! [20:46:10 CET] <flydev> root@enc7-bg:~/ffmpeg_sources/ffmpeg# /root/bin/ffmpeg ffmpeg version N-89387-gd67c1dd Copyright (c) 2000-2017 the FFmpeg developers built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.5) 20160609 [20:46:53 CET] <flydev> Okay, so I need to edit the script to compile from source and do rm ~/ffmpeg_build/lib/libx265.so* + make clean before building ffmpeg? [21:12:05 CET] <TheRock> External libraries: [21:12:05 CET] <TheRock> schannel xlib [21:12:11 CET] <TheRock> what's this for? [21:12:15 CET] <TheRock> and can it be disabled? [21:14:50 CET] <alexpigment> i think schannel is for old TLS support [21:14:58 CET] <alexpigment> you can do --disable-schannel i believe [21:16:03 CET] <alexpigment> i suppose you could try --disable-xlib too, but I'm not sure what that does [21:17:21 CET] <therage3> ok, so [21:17:30 CET] <TheRock> both, got accepted. reconfiguring now. thx [21:17:46 CET] <TheRock> i will see, if it still runs afterwards ;) [21:17:56 CET] <therage3> if CRF for x264 is unchanged, but preset is moved around, the quality of the image stays the same, just the file size that changes, right? [21:18:51 CET] <BtbN> depends [21:18:57 CET] <alexpigment> therage3: I had this understanding as well, but I believe I've heard that the quality changes too [21:19:00 CET] <BtbN> slower presets also enable more features [21:19:01 CET] <alexpigment> which is confusing [21:19:04 CET] <therage3> uh [21:19:05 CET] <therage3> wat [21:19:10 CET] <BtbN> which might result in better quality [21:19:10 CET] <therage3> ok, this is confusing as hell, now [21:19:40 CET] <BtbN> If you set x264 to ultrafast, it will output constained baseline [21:19:44 CET] <alexpigment> therage3: it's most likely because quality is based on the feature set, so you can't guarantee a 1:1 quality level when using different features [21:19:46 CET] <BtbN> Which obviously results in worse quality [21:19:49 CET] <therage3> BtbN, alexpigment, i always thought the quality itself doesn't change, like how a png or flac's compression level changes but the image or the sound is identical otherwise [21:19:52 CET] <kepstin> therage3: in general, the meaning of a particular crf value depends on a bunch of other x264 options, and changing the preset changes some of those options. [21:20:03 CET] <therage3> kepstin: i see, so that's the reason then [21:20:10 CET] <therage3> the crf changes some stuff under the hood! [21:20:11 CET] <therage3> that explains it [21:20:18 CET] <BtbN> no it doesn't [21:20:19 CET] <kepstin> no, the preset changes some stuff [21:20:20 CET] <BtbN> the preset does [21:20:21 CET] <alexpigment> therage3: no, the preset changes things under the hood [21:20:25 CET] <therage3> er [21:20:28 CET] <therage3> yes, sorry [21:20:30 CET] <therage3> the preset* [21:20:31 CET] <BtbN> It's a preset, as the name might suggest [21:20:38 CET] <BtbN> a pre-set set of options [21:20:43 CET] <therage3> ahh interesting [21:21:05 CET] <BtbN> Nobody wants to touch all the multiple dozens of options it has [21:21:09 CET] <kepstin> basically, the x264 preset system was introduced because people kept copy/pasting bad x264 option lists off of forums and wikis [21:21:21 CET] <kepstin> so the devs decided to pick some good ones and put them into presets [21:21:22 CET] <therage3> so the names "slower", "placebo", etc. are just "user friendly" things so that people just think of it in terms of speed [21:21:28 CET] <therage3> and not what actually changes under the hood [21:21:40 CET] <alexpigment> right [21:22:25 CET] <therage3> the problem then of course is that hiding the technical details gives people this misconception [21:22:34 CET] <therage3> the misconception that i addressed myself personally [21:22:47 CET] <therage3> and now know better [21:23:24 CET] <alexpigment> this does bring up a good question though: are the CRF values assigned with the respect to the preset? in other words, is there any code to make CRF 20 look close to each other for both veryfast and slow? [21:23:49 CET] <kepstin> alexpigment: the crf values have no intrinsic meaning, there actually an internal part of the two-pass rate control mechanism [21:24:11 CET] <therage3> so whenever you use crf, internally ffmpeg does a two-pass thing? [21:24:20 CET] <alexpigment> therage3: well, i think it does pass 1 [21:24:26 CET] <therage3> ... [21:24:29 CET] <kepstin> when you do crf, x264 effectively does only the 2nd pass of a two-pass encode [21:24:33 CET] <therage3> ^ [21:24:40 CET] <therage3> that's what i meant, alexpigment [21:24:55 CET] <therage3> why is ffmpeg so complicated [21:24:59 CET] <therage3> none of this is online anywhere [21:25:08 CET] <kepstin> we haven't even gotten into ffmpeg stuff, this is all libx264 ;) [21:25:27 CET] <therage3> everyone just blurts out that presets only change speed of encoding and the size, and if crf is the same, image quality is the same [21:25:54 CET] <therage3> thank God IRC exists [21:26:13 CET] <kepstin> i mean, quality will generally be *close*, as long as you're not comparing ultrafast and veryslow or something like that [21:26:23 CET] <kepstin> but it won't be the same. [21:26:29 CET] <therage3> great, now my ocd is going to kick in [21:26:37 CET] <therage3> why did i have to learn about this ._. [21:27:06 CET] <kepstin> the rule of thumb for using x264 is "pick the slowest preset you can handle, then pick a crf that gives you the quality you want" [21:27:15 CET] <therage3> yeah, that sounds good [21:27:22 CET] <therage3> also, one more thing... i keep reading conflicting information [21:27:24 CET] <kepstin> the downside is that doing a fast test encode won't give you a completely accurate idea of quality. [21:27:26 CET] <alexpigment> I use medium CRF 18 on most things fwiw [21:27:39 CET] <therage3> is crf 0 lossless in the true sense of that word? [21:27:47 CET] <alexpigment> because hard drives are cheap and my time is valuable [21:27:48 CET] <therage3> because here's the issue [21:27:57 CET] <alexpigment> therage3: yes [21:28:03 CET] <kepstin> therage3: with 8bit x264 yes, with 10bit, no. Use the "-qp 0" option instead which is lossless in both. [21:28:04 CET] <therage3> crf 0 is one thing, but depending on preset, that then changes, right? [21:28:26 CET] <alexpigment> kepstin: there you go screwing up my understanding of the universe again ;) [21:28:37 CET] <therage3> my brain just exploded a second time again today [21:28:52 CET] <alexpigment> crf 0 will be lossless for 8-bit (apparently) at any preset, but the file size will change depending on the preset [21:28:54 CET] <therage3> then again i see yup420 or whatever on most of my stuff which i think is 8-bit [21:29:18 CET] <alexpigment> yuv420p is different than the depth [21:29:31 CET] <alexpigment> 4:2:0 is chroma subsampling [21:29:33 CET] <kepstin> note that using -qp 0 or -crf 0 (on 8-bit) triggers a separate lossless mode, and it doesn't follow the normal crf pattern really [21:29:35 CET] <alexpigment> 8-bit is the bit depth [21:29:43 CET] <therage3> ahhhh i see kepstin [21:29:54 CET] <therage3> that explains why it's truly lossless regardless of preset then [21:29:57 CET] <kepstin> both options do exactly the same thing [21:30:06 CET] <alexpigment> crf 0 will also change your profile to yuv444pp i believe [21:30:44 CET] <alexpigment> which, for compatibility reasons, can be problematic. then again, a crf 0 video is likely to be problematic for playback anyway due to the bitrate [21:30:51 CET] <kepstin> you can still encode yuv420p in lossless, but the h264 profile with be one that requires the decoder support 4:4:4 modes [21:30:52 CET] <therage3> yeah i know [21:30:53 CET] <therage3> i figured [21:31:02 CET] <therage3> i just asked out of curiosity [21:31:40 CET] <therage3> i guess unlike png and flac, there's nothing that takes a DVD or a BluRay and compresses it losslessly yielding a smaller filesize, to my knowledge [21:31:51 CET] <therage3> because my experiments with crf 0 was GINORMOUS file [21:32:00 CET] <kepstin> therage3: that's impossible, because DVD and Bluray are already encoded with a lossy codec [21:32:05 CET] <therage3> right i see [21:32:14 CET] <alexpigment> most modern formats are optimized to the point where you couldn't save much anyway at lossless quality [21:32:38 CET] <kepstin> I mean, you can re-encode a DVD to a way smaller file with no *visible* loss using x264 [21:32:38 CET] <alexpigment> modern codecs are usually only better at "looking better" while being lossy [21:32:52 CET] <alexpigment> lossless encoding doesn't have much to optimize [21:33:33 CET] <kepstin> but using a lossless codec to re-encode a lossy source makes no sense, because the lossless codec has to carefully and perfectly reproduce all the artifacts added by the original lossless codec. [21:33:38 CET] <alexpigment> unlike PNG and FLAC, which were based on very old compression standards [21:33:50 CET] <alexpigment> rather, they were improvements on old standards [21:33:54 CET] <therage3> kepstin: i guess what i meant is, lossless with respect to the master one possesses (in this case, a DVD or a Blueray), but yeah i understand [21:33:57 CET] <alexpigment> (BMP and WAV) [21:34:06 CET] <jfmcarreira> heyy guys. I am using the following code to read stream using libav: http://dpaste.com/1HAP5PQ [21:34:09 CET] <kepstin> (I mean, it might be useful as a temp file if you're doing multi-step edits to avoid more generation loss than necessary) [21:34:11 CET] <therage3> like, we don't have the 16mm film elements from the studio, of course [21:34:28 CET] <jfmcarreira> However the function av_read_frame is always returning EOF error [21:36:37 CET] <alexpigment> therage3: one other thing to keep in mind about CRF is that you need to choose based on the resolution of the original media. you notice the lack of quality more on SD sources, presumably because the pixels are going to be bigger when you fullscreen [21:37:02 CET] <alexpigment> so you might be able to get away with CRF 22 or something on an HD video, but CRF 22 is getting into that "too lossy" territory for SD content [21:37:21 CET] <therage3> alexpigment: yes, precisely. this is evident on the cartoon we were discussing some days ago, from which i still cannot eliminate that pesky hard telecine [21:37:31 CET] <therage3> i just use a filter for it in the media player :D [21:38:17 CET] <alexpigment> yeah, fortunately, cartoons compress well [21:38:25 CET] <therage3> there's a problem though [21:38:32 CET] <alexpigment> you can just set the CRF to something really low (like 14-16) and just leave it [21:38:36 CET] <therage3> the compressed lossy version apparently throws the filter off [21:38:43 CET] <therage3> and it doesn't eliminate it that well [21:39:02 CET] <alexpigment> i can understand how that would happen [21:39:23 CET] <alexpigment> if you are trying to match fields and you have more compression artifacts in one field compared to the matching other field, then it might not see them as the same [21:39:29 CET] <therage3> exactly [21:39:53 CET] <alexpigment> having said that, I never really have that problem with detelecine on lossy sources [21:39:54 CET] <therage3> but when i play back the uncompressed mkv, which is just a stream copy from the dvd mpeg2 stream, it does it flawlessly [21:39:58 CET] <alexpigment> i've never tried to use fieldmatch though [21:40:05 CET] <therage3> well, note that i did use crf 22 [21:40:12 CET] <therage3> so i may need to use lower values and then test [21:40:30 CET] <alexpigment> yeah, I have no idea of the sensitivity of the filter [21:40:49 CET] <therage3> i asked in #videolan and nobody knew [21:40:54 CET] <therage3> (it's VLC's IVTC filter) [21:42:09 CET] <alexpigment> out of curiosity, did you use interlaced encoding when you tried CRF 22? [21:42:19 CET] <alexpigment> the source would have been interlaced [21:42:34 CET] <therage3> let me copy the command i used [21:42:43 CET] <alexpigment> but you have to expliclitly specify interlaced when encoding with x264 [21:43:17 CET] <therage3> ffmpeg -i input -c:v libx264 -preset slower -crf 22 -c:a copy output [21:43:20 CET] <alexpigment> ah [21:43:22 CET] <alexpigment> yeah [21:43:35 CET] <therage3> just a standard x264 call with an audio stream copy [21:43:39 CET] <alexpigment> -x264-params +ildct+ilme [21:43:39 CET] <therage3> nothing fancy [21:43:50 CET] <alexpigment> er [21:43:52 CET] <alexpigment> sorry [21:43:53 CET] <therage3> what? [21:44:00 CET] <alexpigment> -flags +ildct+ilme [21:44:21 CET] <alexpigment> add that to your command [21:44:24 CET] <therage3> i don't know what that is. are those parameters to pass to the encoder? [21:44:28 CET] <therage3> what do they do? [21:44:43 CET] <alexpigment> they basically make sure that your output is interlaced [21:44:58 CET] <alexpigment> an IVTC filter probably assumes that your content is interlaced [21:45:06 CET] Action: therage3 raises an eyebrow [21:45:15 CET] <alexpigment> i mean true telecined content *is* interlaced [21:45:25 CET] <therage3> why did i ever get involved in video encoding, this is so complicated lol [21:45:40 CET] <alexpigment> therage3: yep [21:46:12 CET] <alexpigment> there's a lot of job security in knowing the complexities though :) [21:46:55 CET] <therage3> here's my confusion though ... when you say "true telecined content *is* interlaced", you don't mean all frames, right? just in a set pattern, some of them, and some are progressive [21:47:23 CET] <alexpigment> MPEG-2 is either interlaced or progressive [21:47:30 CET] <alexpigment> there's no hybrid mode to my knowledge [21:47:56 CET] <alexpigment> whereas x264 has MBAFF, which is a hybrid progressive/interlaced thing [21:48:03 CET] <therage3> so even if actual visible frames may appear progressive, the actual stream is either interlaced or progressive [21:48:09 CET] <therage3> and if some are interlaced, the whole stream is [21:48:28 CET] <alexpigment> well, I suppose there could be a change midstream or something [21:48:37 CET] <therage3> jesus christ [21:48:41 CET] <alexpigment> but in general, it's not actively switching between the two [21:49:01 CET] <therage3> (i'm not frustrated at you, it's just that this is all so complicated :D) [21:49:08 CET] <alexpigment> just assume that if you have something telecined, it's interlaced [21:49:21 CET] <alexpigment> it's been converted from ~24p to 30i [21:49:38 CET] <therage3> right, from the studio 16mm film elements to broadcast [21:49:45 CET] <therage3> or 35mm, w/e [21:49:51 CET] <alexpigment> yeah [21:50:13 CET] <alexpigment> anyway, let me know if adding that stuff above makes the player do the correct ivtc [21:50:14 CET] <therage3> (this is a show that aired from 1993 to 1995, so yeah, that's likely it) [21:50:26 CET] <therage3> i see, well, after this encode i'll add those flags and let you know. do i keep crf at 22? [21:50:55 CET] <alexpigment> sure. although i'd personally go lower, but that's up to you [21:51:29 CET] <therage3> yeah, i may do that for an actual rip that i use, but now i wanted to see if this helps the IVTC filter in picking up interlaced frames [21:51:39 CET] <alexpigment> yeah, the crf doesn't matter for this test [21:51:46 CET] <alexpigment> *shouldn't* matter for this test [21:52:45 CET] <therage3> yeah [21:52:59 CET] <therage3> another thing that messed with my head something bad was the SAR and the DAR [21:53:06 CET] <alexpigment> haha, yeah [21:53:30 CET] <alexpigment> anytime I have to fix aspect ratio stuff in handbrake, I'm like "uhhh... ?" [21:53:30 CET] <therage3> the display resolution is apparently 720 x 480... so far so good. but whenever i uploaded it to YouTube, for whatever reason, it would be 640 x 480 [21:53:37 CET] <alexpigment> oh [21:53:40 CET] <alexpigment> yeah, that's dvd for you [21:53:53 CET] <therage3> apparently YouTube actually looks at the file's DAR and SAR and uses _that_ [21:53:53 CET] <alexpigment> dvd is always 720x480 for ntsc [21:54:13 CET] <alexpigment> but the dislay aspect is 640x480 for 4x3 (it horizontally compresses the source) [21:54:18 CET] <therage3> yes, lol [21:54:29 CET] <alexpigment> or it's ~853x480 for 16x9 [21:54:38 CET] <alexpigment> and it stretches the original width [21:54:55 CET] <alexpigment> so when youtube is making it 640x480, it's doing the right thing [21:55:29 CET] <therage3> yeah [22:02:54 CET] <therage3> alexpigment: OK, encoding now [22:03:29 CET] <therage3> ffmpeg -i input -c:v libx264 -preset slower -crf 22 -flags +ildct+ilme -c:a copy output [22:03:32 CET] <therage3> this is the command i used [22:06:12 CET] <alexpigment> yeah, that should be fine [22:07:00 CET] <alexpigment> i've been one of those flags isn't needed (maybe ilme?) for x264, but I just use that across the board with various encoders, and it doesn't hurt anything [22:07:21 CET] <alexpigment> mpeg2video i think requires both [22:07:39 CET] <alexpigment> anyway, the point being is that what you have is good [22:08:48 CET] <therage3> nice [22:09:05 CET] Action: therage3 sits back and waits for this mobile i5 to finish encoding .) [22:09:06 CET] <therage3> :) [22:25:15 CET] <rajkosto> :( cant seem to get rid of the implicit 2 frame buffer on h264 decode [22:26:39 CET] <BtbN> Have you tried using the new API? [22:26:49 CET] <rajkosto> yes [22:26:58 CET] <rajkosto> i dont understand what buffer_frame is for in send_packet [22:27:14 CET] <rajkosto> thats one of the frames that delays it [22:27:49 CET] <BtbN> buffer_frame in send_packet? [22:28:40 CET] <rajkosto> bceause it eats the first decode result, receive_frame afterwards returns EAGAIN as the packet buffer is empty (was eaten to fillup buffer_frame) [22:29:15 CET] <BtbN> What code are you even looking at? [22:29:38 CET] <rajkosto> https://images.sshnuke.net/2017-12-04_22-29-35.png [22:29:49 CET] <BtbN> That's a screenshot [22:29:51 CET] <BtbN> of code [22:30:01 CET] <rajkosto> thats what im looking at ? [22:30:06 CET] <rajkosto> its avcodec_send_packet, the "new" interface [22:30:20 CET] <BtbN> Where in the codebase is it? In the h264 decoder? [22:30:25 CET] <rajkosto> decode.c [22:31:23 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/decode.c;h=3f5b08… [22:31:24 CET] <rajkosto> nevermind, it doesnt eat it, receive_frame will fetch from it if its full [22:31:44 CET] <rajkosto> but its not full in my case, even when i gave it enough nals for an IDR slice [22:32:07 CET] <JEEB> have you checked if the decoder just doesn't /always/ block according to the limit in SPS? [22:32:17 CET] <rajkosto> how [22:34:05 CET] <JEEB> http://up-cat.net/p/1c0e32af [22:34:20 CET] <JEEB> not too many places where has_b_frames is used with H.264 :P [22:57:51 CET] <rajkosto> JEEB, yes but i still have no clue how internally the ffmpeg decoder buffering works [23:22:34 CET] <therage3> alexpigment: this is an interesting turn of events [23:23:24 CET] <alexpigment> therage3: in the sense that the ivtc now works? [23:23:56 CET] <therage3> alexpigment: i just ran the original DVD vob file (to ensure i'm using the original) through MediaInfo, and apparently this thinks it's "Interlaced" and not "2:3 pulldown" or whatever it calls telecine [23:24:08 CET] <alexpigment> yeah, that's normal [23:24:10 CET] <alexpigment> it *is* interlaced [23:24:19 CET] <therage3> o.o [23:24:20 CET] <alexpigment> and the pulldown is not a flag [23:24:49 CET] <alexpigment> at least in this case [23:24:55 CET] <alexpigment> that's why it's a "hard telecine" [23:25:18 CET] <therage3> ... so the actual video itself is burned, as is, telecined, onto the dvd [23:25:30 CET] <therage3> and not brought up to 30fps with a flag [23:25:30 CET] <alexpigment> https://en.wikipedia.org/wiki/Telecine#2:3_pulldown [23:25:33 CET] <alexpigment> yeah [23:25:45 CET] <alexpigment> i mean, i can't tell for sure without seeing it, but most likely that is the case [23:25:51 CET] <therage3> jesus christ it's like i'm getting a master's degree in video processing <.< [23:25:55 CET] <alexpigment> haha [23:26:20 CET] <sfan5> don't worry there's more [23:26:27 CET] <therage3> i bet, sfan5 [23:27:19 CET] <alexpigment> but the thing is that the fields are all there and the patterns can be detected to reconstruct a true 24p (or 23.976p) source [23:28:29 CET] <therage3> yeah, i see, and the trick is to use a filter that's intelligent enough to detect those and bring the framerate down after duplicate decimation and combination [23:28:36 CET] <alexpigment> yep [23:28:37 CET] <therage3> that's the part where i'm struggling [23:29:28 CET] <alexpigment> well, have you tried handbrake? [23:29:41 CET] <alexpigment> i've always had good luck with their detelecine filter [23:29:57 CET] <alexpigment> just set it to "default", then I manually set the frame rate to 23.976 [23:30:16 CET] <alexpigment> not sure if that'll be different than what ffmpeg does, but it's generally always worked for me [23:31:04 CET] <therage3> uhm yeah [23:31:20 CET] <therage3> the problem with handbrake is that it uh, like, what does it do with the aspect rations and the border cropping [23:31:23 CET] <therage3> it has a mind of its own [23:31:27 CET] <therage3> i want it to leave that stuff alone [23:31:33 CET] <alexpigment> yeah, that's pretty easy to do [23:31:40 CET] <therage3> how o.o [23:31:43 CET] <alexpigment> manual crop and set each side to 0 [23:31:52 CET] Action: therage3 opens Handbrake o.o [23:31:54 CET] <therage3> hold on [23:32:01 CET] <alexpigment> then turn anamorphic to automatic [23:32:46 CET] <therage3> i see [23:33:14 CET] <therage3> "then I manually set the frame rate to 23.976" OH [23:33:16 CET] <therage3> i see [23:33:23 CET] <therage3> that's the part i wasn't doing in Handbrake [23:33:36 CET] <alexpigment> well, i think there's an auto mode for the frame rate [23:33:38 CET] <therage3> i thought the detelecine filter would get rid of the duplicates itself [23:33:41 CET] <alexpigment> but i generally set it explicitly [23:34:03 CET] <alexpigment> maybe it's because i don't trust the wording of "same as source" [23:34:09 CET] <alexpigment> the source is 30 [23:34:10 CET] <alexpigment> so [23:34:13 CET] <alexpigment> ....? [23:34:30 CET] <alexpigment> because of that wording, i've always explicitly set the frame rate [23:34:49 CET] <therage3> it's also confusing, if it's a soft telecine maybe it reads the flag and adjusts it, if it's hard, it uses 30 [23:34:53 CET] <therage3> go figure [23:34:57 CET] <alexpigment> maybe so [23:35:07 CET] <alexpigment> i so rarely deal with soft telecined content, that I'll admit ignorance on that [23:35:15 CET] <alexpigment> almost everything i deal with is hard telecined [23:35:27 CET] <therage3> goddamn i wish the TV broadcast industry and Hollywood had the same standards [23:35:30 CET] <therage3> this is so annoying [23:36:40 CET] <alexpigment> well, if hollywood ruled all, then you'd never see anything above 24fps [23:36:48 CET] <alexpigment> and that would be a sad jerky world ;) [23:37:00 CET] <therage3> frankly, after this headache, i may be ok with tat [23:37:01 CET] <therage3> that* [23:37:08 CET] <therage3> it'd spare me having to learn this stuff [23:37:16 CET] <alexpigment> therage3: this is all making you stronger [23:37:19 CET] <alexpigment> you're like the hulk now [23:37:21 CET] <therage3> i hope so [23:39:31 CET] <therage3> alexpigment: anyway in handbrake, modulus is 2? and leave width and height as is? [23:39:47 CET] <alexpigment> modulus 2 is fine [23:40:07 CET] <therage3> i see [23:40:10 CET] <alexpigment> assuming your crop is set to 0 on all sides, then make sure the height is 480 [23:40:19 CET] <alexpigment> it doesn't update that number dynamically for some reason [23:40:24 CET] <alexpigment> or not in my experience at least [23:41:16 CET] <therage3> i see [23:42:06 CET] <therage3> alexpigment: are detelecine and deinterlace supposed to be used together? [23:42:10 CET] <alexpigment> no [23:42:12 CET] <alexpigment> one or the other [23:42:23 CET] <alexpigment> just use detelecine [23:42:33 CET] <therage3> right, i see....... i was wondering what detelecine even did if it didn't switch off deinterlae [23:42:41 CET] <alexpigment> it does, actually [23:42:47 CET] <alexpigment> it's just that it does it in a different way [23:43:05 CET] <alexpigment> deinterlace only looks at the two fields when creating progressive frames [23:43:19 CET] <alexpigment> detelecine looks at the bigger pattern and combines fields from different frames [23:43:33 CET] <alexpigment> you use them in different contexts [23:43:35 CET] <therage3> right, i see [23:47:03 CET] <therage3> all right, outputting this video at 23.976 fps with the detelecine thing [23:47:06 CET] <therage3> let's see how it does [23:47:11 CET] <alexpigment> cool [23:47:18 CET] <alexpigment> btw, you can do "preview" to test it out [23:47:26 CET] <alexpigment> just so you don't waste a lot of time on something that doesn't work [23:47:29 CET] <alexpigment> or that isn't optimal [23:47:32 CET] <alexpigment> *optimal [23:47:48 CET] <alexpigment> (weird, i thought i typo'd but i didn't) [23:53:29 CET] <therage3> alexpigment: handbrake is being annoying again :) for some reason it insists on changing the resolution... on the original, 720x480 is both the resolution and the display resolution [23:53:41 CET] <therage3> now the resolution is 720x482 for whatever reason [23:54:06 CET] <alexpigment> ok, then set the anamorphic to "Loose" [23:54:10 CET] <alexpigment> set the height to 480 [23:54:19 CET] <alexpigment> the width should stay at 720 [23:54:23 CET] <therage3> ... uh [23:54:26 CET] <alexpigment> even when you switch back and forth between tabs [23:54:34 CET] <therage3> i set it to loose and the Height field became grayed out [23:54:47 CET] <alexpigment> ok, but the width is 720, right? [23:54:51 CET] <therage3> yes [23:54:54 CET] <alexpigment> you're fine then [23:55:05 CET] <alexpigment> see, handbrake is by default catered to 'dumb' progressive video [23:55:06 CET] <therage3> phew [23:55:16 CET] <alexpigment> and by that i mean that it takes out anything that might confuse a player [23:55:19 CET] <alexpigment> like interlacing [23:55:22 CET] <alexpigment> or like aspect ratio [23:55:25 CET] <alexpigment> etc [23:55:39 CET] <therage3> this is what i mean when i say Handbrake annoyed me [23:55:39 CET] <therage3> like, it has a mind of its own [23:55:43 CET] <alexpigment> right [23:55:49 CET] <alexpigment> if you make a preset, it'll stick usually [23:55:57 CET] <therage3> i see [23:56:00 CET] <alexpigment> although different sources can still cause it to rescan or certain values [23:56:18 CET] <alexpigment> it's not the best program in the world, but I have some things I record regularly and process in batches [23:56:36 CET] <alexpigment> and handbrake makes that process pretty easy while giving me access to additional command line options for x264 [23:56:50 CET] <therage3> yeah so i see [23:57:03 CET] <therage3> don't get me wrong, the program is good if you know its quirks and how to tame it [23:57:07 CET] <alexpigment> like i always specify the gop at the same length as the frame rate in the "extra options" field [23:57:27 CET] <alexpigment> therage3: precisely. and i guarantee you that most people don't know its quirks or how to use it [23:57:30 CET] <therage3> but how one is supposed to figure out that to get it to stop randomly making up its own resolutions, one has to hunt for "Anamorphic" and set it to "Loose", well... [23:57:33 CET] <therage3> it's not trivial [23:57:37 CET] <alexpigment> but it does make some assumptions that are probably best for most users [23:57:53 CET] <alexpigment> well, the thing is, you're trying to get it to stick to the source resolution [23:57:56 CET] <alexpigment> most people aren't [23:57:58 CET] <therage3> yes [23:58:30 CET] <alexpigment> it's a 4:3 dvd, so they assume that you want to encode at 640x480 so that the player doesn't have to stretch it to that resolution anyway [23:58:38 CET] <alexpigment> and honestly, that's a perfectly fine assumption [23:59:14 CET] Action: therage3 raises an eyebrow [23:59:18 CET] <therage3> it's doing what YouTube does [23:59:19 CET] <therage3> i see [00:00:00 CET] --- Tue Dec 5 2017

1 0

ffmpeg-devel.log.20171203
by burek 04 Dec '17

04 Dec '17

[00:55:22 CET] <SortaCore> (SOCKET)*(*(*(((int ***)rtsp_format_context->priv_data) + 1) + 2) + 1); [00:56:26 CET] <wm4> beautiful [00:56:34 CET] <wm4> (wat) [01:16:02 CET] <jcdutton> Hi. Is the mailing list broken? It will not let me subscribe [01:20:13 CET] <jamrial> jcdutton: not that i know of [01:20:20 CET] <jamrial> Compn: ^ [01:22:21 CET] <jamrial> BBB: http://coverage.ffmpeg.org/libavcodec/vp9_superframe_bsf.c.gcov.html collateral damage of keeping packet splitting strictly within the decoder [01:23:27 CET] <jamrial> i mean, in a way it's much better now since there's no way to mux broken files anymore, but this filter is essentially untested now :p [01:26:25 CET] <wm4> there are other BSFs for fixing obscure things [01:26:35 CET] <wm4> like the one for mpeg4 [01:26:51 CET] <wm4> also mp3_header_decompress maybe [01:27:28 CET] <wm4> whatever their use is... [01:28:17 CET] <wm4> (not sure if those have coverage) [01:28:28 CET] <jamrial> it was two filters, compress and decompress. the former was removed since the gains were minimal, but the latter was left in place to prevent rendering files created with the former unreadable [01:29:14 CET] <jamrial> mpeg4_unpack_bframes is tested, yes [01:30:20 CET] <Compn> jcdutton : did it give you an error message ? [01:32:13 CET] Action: Compn approves a couple patches stuck in mod queue [01:33:03 CET] <Compn> jcdutton : if you tell me your mail i can check your subscription status ? [01:33:11 CET] <Compn> or subscribe you manually [01:33:12 CET] Action: Compn afk [01:34:11 CET] <daddesio> jcdutton: I just subscribed today, using gmail. [01:34:42 CET] <daddesio> and I was able to submit my patchset fine, after confirming my email. [01:37:43 CET] <Compn> daddesio : you are getting mails from the list ? [01:37:59 CET] <Compn> could be problem with ffmpeg mail ip is in a sorbs blacklist [01:38:00 CET] <Compn> :\ [01:41:01 CET] <Compn> nope [01:41:04 CET] <Compn> just a problem with gmail labels [01:41:07 CET] <Compn> everything is a-ok [01:41:08 CET] Action: Compn runs [01:42:47 CET] <BBB> jamrial: how can it be untested? [01:42:56 CET] <BBB> jamrial: we have a fate file that uses it [01:43:07 CET] <BBB> jamrial: one of the fate samples uses superframes and should thus use the bsf [01:43:39 CET] <BBB> oh I see [01:43:40 CET] <BBB> the inverse [01:43:41 CET] <BBB> hm [01:43:41 CET] <BBB> yes [01:43:42 CET] <BBB> well... [01:43:46 CET] <BBB> thats your problem :-p [01:43:51 CET] <BBB> maybe we dont need it anymore? [01:43:54 CET] <BBB> I dont know [01:44:05 CET] <BBB> jamrial: if you want to remove it, Im ok with it [01:45:43 CET] <jamrial> no, i don't [01:45:59 CET] <jamrial> just pointing that the existing test is not using it anymore :p [01:46:51 CET] <jamrial> short of using a broken file (one muxed without it before the parser changes), there's probably no way to test it [02:23:57 CET] <cone-899> ffmpeg 03Michael Niedermayer 07master:4bb7d72bcfb5: avcodec/h264_parse: Treat escaped and unescaped decoding error equal in decode_extradata_ps_mp4() [03:48:11 CET] <atomnuker> daddesio: yeah, I really don't think that the opus decoder should be able to downmix by itself [03:49:25 CET] <atomnuker> can you figure out how -ac 1 could get piped to it so we can test it (I don't think it can, ffmpeg should autoinsert a swr downmix for you) or just remove that codepath entirely? [04:44:20 CET] <hanna> JEEB: I think those benchmarks are out-of-date now [04:49:43 CET] <TD-Linux> there is an optional way to do downmixing in libopus where you don't do the stereo phase flips [04:50:51 CET] <atomnuker> decoder side downmixing is ridiculous nevertheless [04:51:23 CET] <atomnuker> if this was sanely designed by ac-3 we'd have some sort of side data that real downmixers could use [05:06:35 CET] <SortaCore> @wm4: lets me access rtsp's socket so I can check bytes_available and guess whether a read call will block [05:35:05 CET] <SortaCore> there's always *some* data available, but if there's not enough for a H264 frame, I can leave it for a bit [05:35:35 CET] <SortaCore> that's for single-threaded mode though, for multithreaded I don't bother [06:09:16 CET] <cone-909> ffmpeg 03Jim DeLaHunt 07master:42a22d01d1a0: doc: reorganize developer.texi chapter hierarchy [11:33:55 CET] <durandal_1707> who is working on sbc integration? [11:34:24 CET] <atomnuker> no, I think the author's too busy [11:34:56 CET] <atomnuker> weren't that much things to do to it though, I'll just ping the thread [12:14:20 CET] <BtbN> http://git.videolan.org/?p=ffmpeg/nv-codec-headers.git;a=summary is a thing now. [12:25:16 CET] <durandal_1707> do same for avisynth so we can ditch both [19:19:27 CET] <cone-856> ffmpeg 03Martin Vignali 07master:fa470384ea3f: avfilter/vf_threshold : move context func init in ff_threshold_init [19:19:28 CET] <cone-856> ffmpeg 03Martin Vignali 07master:cfce4427503a: checkasm/vf_threshold : add checkasm test for threshold8 [19:19:29 CET] <cone-856> ffmpeg 03Martin Vignali 07master:51345cb1d553: avfilter/x86/vf_threshold : make macro for threshold8 in order to add avx2 version [19:19:30 CET] <cone-856> ffmpeg 03Martin Vignali 07master:9719d57b34f2: avfilter/x86/vf_threshold : add avx2 version for threshold 8 [19:19:31 CET] <cone-856> ffmpeg 03Martin Vignali 07master:6e3e69659148: avfilter/x86/vf_threshold : cosmetic indent [20:05:26 CET] <JEEB> I don't think our H.264 decoder can even give you the frames in the incorrect order? so if someone's "latency' is coming from reordering I can only tell him "too bad" [20:09:21 CET] <nevcairiel> if you set the low latency flag i believe you can [20:09:39 CET] <JEEB> oh [20:13:00 CET] <JEEB> don't see an avoption and has_b_frames isn't poked in h264dec.c [20:13:19 CET] <JEEB> the person I'm trying to help in #ffmpeg is focused only on decoding so most likely no avformat [20:13:59 CET] <JEEB> but I already told him that reordering is a requirement in the decoder so if the stream requires reordering then rip [20:14:00 CET] <nevcairiel> -flags low_delay [20:14:02 CET] <nevcairiel> i believe [20:14:35 CET] <JEEB> doesn't seem to be utilized in H.264 decoder [21:53:22 CET] <cone-856> ffmpeg 03Marton Balint 07master:5a93a85fd0ad: avformat/mxfdec: fix last packet timestamps [23:59:23 CET] <atomnuker> durandal_1707: does setrange solve an issue when dropping YUVJ or was it just missing? [00:00:00 CET] --- Mon Dec 4 2017

1 0

ffmpeg.log.20171203
by burek 04 Dec '17

04 Dec '17

[00:04:51 CET] <[-T-]> pp [03:03:42 CET] <jlozadad> hello, anyone knows if they are any other rpms that are needed installed to build from source? i'm getting "libmfx not found using pkg-config" I'm on fedora 27 [03:04:06 CET] <jlozadad> I have libmfx and libmfx-devel installed [03:04:27 CET] <JEEB> see ffbuild/config.log for details [03:05:31 CET] <tdr> jlozadad, the -dev package for that so it has the headers, it could be a version issue too [03:07:32 CET] <jlozadad> so i'm trying to ffmpeg-3.3.5-2 from fedora 27. I was following a guide and it made me get the source rpm for that unpack it and work from there. Is that the right approach? sorry new to this and trying to learn [03:08:14 CET] <tdr> sure if you use the srpm it should give you a spec file that does the rpm building [03:08:57 CET] <jlozadad> ok i'll look at it [03:08:59 CET] <jlozadad> thanks [03:09:01 CET] <tdr> but it probably will not satisfy all the deps so you'll need to pay attention to what it cannot find (or what is/is not enabled) when its running autoconfigure (./configure part) [03:10:08 CET] <jlozadad> ok, I will verify it ty! appreciate the help [03:10:11 CET] <tdr> many times "not found" is just the dev package not found, but you said you had it for that one [03:10:41 CET] <tdr> jlozadad, are you using rpm to build it or doing it manually? [03:11:17 CET] <tdr> jlozadad, be aware if its trying to build it multilib you'll need the .686 packages too if they exist for the deps [03:12:24 CET] <jlozadad> yes, trying to run ./configure then make make install [03:12:58 CET] <tdr> you should prob just use rpm on an rpm based distro [03:13:31 CET] <jlozadad> alright :) I guess also a good learning exp :) ty for the help [03:15:29 CET] <tdr> only because rpm based distros dont always put headers etc in the usual places or do things "normal" [03:16:17 CET] <furq> do you actually need libmfx on linux [03:16:28 CET] <furq> i'm pretty sure vaapi is the recommended way to use qsv now [03:17:58 CET] <jlozadad> was trying to follow this guide but, its mostly in ubuntu and i'm trying to translate it to fedora wise https://www.gamingonlinux.com/articles/using-nvidias-nvenc-with-obs-studio-… [03:18:48 CET] <furq> you definitely don't need mfx for nvenc [03:19:20 CET] <furq> you also don't really need fdk any more [03:19:24 CET] <furq> the builtin aac encoder is fine now [03:20:48 CET] <furq> if the fedora packaged version is recent then nvenc and aac should just work out of the box [03:20:51 CET] <furq> the nvenc stuff is builtin now [03:22:01 CET] <jlozadad> so I don't need to build it like its mentioning in the guide? [03:22:44 CET] <furq> probably not [05:18:29 CET] <hiihiii> hello. I'm trying to encode an input with two audio channels, have each channel normalized differently, then resample to mono [05:19:43 CET] <hiihiii> currently I'm just doing -i input -c:a aac -af "loudnorm,aformat=channel_layouts=mono" output [05:22:40 CET] <hiihiii> I know I could just split audio, normalize the two separately, then join them again [05:23:10 CET] <hiihiii> but I'm more interested to know how to access the channel streams [05:41:01 CET] <hiihiii> ah 0:a:0 and 0:a:1 [07:38:12 CET] <mistym> When writing a muxer for libavformat, is there a way in AVOutputFormat to indicate that more than one `audio_codec` is possible? [07:56:19 CET] <traw> There can be any problem if av_register_all is called twice? [07:59:43 CET] <atomnuker> nope [07:59:55 CET] <atomnuker> not even if they're called from different threads at the same time [08:00:52 CET] <traw> ok [08:04:14 CET] <traw> I'm using webrtc-native with ffmpeg support, which have implementation for h264 decoder, decoder internally calls av_register_all, but in that case av_guess_format fails to find any format [12:40:02 CET] <durandal_1707> mistym: no, you need to add default codec, for all rest you need manually check if it is supported [12:40:50 CET] <mistym> durandal_1707: OK, thanks! [14:23:14 CET] <zyme> Good Morning ppl (depending on where you are). Any one awake yet/or/still? [14:24:29 CET] <sfan5> the probability of all 407 other people in this channel being asleep right now is quite small [14:27:58 CET] <zyme> I would hope but I've seem plenty bigger channels go on for days+ without a word. [14:28:13 CET] <TheRock> o [14:28:15 CET] <TheRock> im here [14:28:23 CET] <TheRock> but i am gonna watch a porn now [14:28:24 CET] <TheRock> afk [14:29:28 CET] <zyme> Sorta like a digital crack house, lol - eveyones passed out for days on end in an intentail coma/paralized like state. anyways... [14:33:40 CET] <zyme> I was wondering two things if they have an answer, the first is when encoding/transcoding into h264 (and probably some others) theres usually a handful of options for amount of CPU usage, the desctiption stating that higher settings are both higher quality and smaller in size at the say time (so I assume its when using a lossy type method) - [14:34:19 CET] <TheRock> im uout the question is too difficult [14:34:44 CET] <zyme> Im only half done typing it =P [14:35:56 CET] <zyme> assuming with ffmpeg your not specifying a bitrate, why isn't it possible to set highest possible cpu usage towards quality with lowest possible cpu usage for compression? [14:37:43 CET] <zyme> I want it done as fast as possible and space wasted doesn't matter I just want it to be high quality - as close to lossless as lossy mode can get under the maximum bitrate for L4.1 [14:38:11 CET] <sfan5> -b:v <what ever is max for L4.> -preset ultrafast [14:38:14 CET] <jkqxz> Just set it to the maximum bitrate for level 4.1. [14:38:23 CET] <JEEB> uhh [14:38:31 CET] <zyme> (which is something like 52mbit/s I think? or maybe something slightly higher?) [14:38:39 CET] <jkqxz> If the input is simple enough that it encodes losslessly with less than that then it will. [14:39:02 CET] <zyme> thats fine too [14:39:03 CET] <pafurijaz> Hi, I can't compile anymore ffmpeg. The first error was this "libopencore_amrnb is version3 and --enable-version3 is not specified. " and I solved it. now, however, it gives me this error. "ERROR: libmp3lame >= 3.98.3 not found" [14:39:40 CET] <zyme> in that case I want my cpu to idle a bit if anything, lol [14:39:42 CET] <JEEB> generally people don't need their streams to follow all the limitations of level 4.1 (the maxrate/bufsize) [14:39:47 CET] <JEEB> and also [14:39:50 CET] <JEEB> there's a misconception [14:39:57 CET] <JEEB> there's two levers [14:40:01 CET] <zyme> which is? [14:40:11 CET] <JEEB> one controls the rate control, and then there's one that sets how much time x264 utilizes for compression [14:40:37 CET] <JEEB> rate control is either CRF (default is CRF=23) or bit rate, and presets are presets [14:41:49 CET] <JEEB> so if you want to utilize the minimum amount of time for encoding, you set the preset to the fastest value that is fast enough for you, and then you set CRF to some low value. for level 4.1 you can set "-level 4.1" or "-level 41" [14:42:37 CET] <sfan5> yeah that also works [14:42:56 CET] <sfan5> there's more restrictions than just bitrate for the different levels anyway [14:43:41 CET] <zyme> so is there some preset I need to change? because I keep trying to transcode and, not caring if the new format should be able to make the same image smaller losslessly - I don't mind it being several times the size in output but speed is an issue because its being done with segmented outputs that are played in a refreshing playlist of sorts for streaming purposes. [14:43:42 CET] <JEEB> the bit rate is anyways something that most decoders don't care too much about, and you don't limit it with the -b:v bit rate general param [14:43:48 CET] <jkqxz> Does level do anything in CRF mode? I thought it just set level_idc and didn't really care otherwise. [14:44:07 CET] <JEEB> jkqxz: it does nowadays limit refs in libavcodec/libx264.c [14:44:20 CET] <JEEB> which is the important thing in levels (memory usage) [14:47:25 CET] <zyme> I feel like I should use an older codec would suit my needs better but the hardware decoder I have while handeling most h.264 L4.1 and lower - well I've found that undocumentedly it will play h.263 in from DIVX encoder (as long as its mkv or mp4) but not XVID or most other h.263's... [14:48:34 CET] <zyme> I actually have a registered copy of Divx but it doesn;t exactly have a ffmpeg cli equivalent I;m aware of, [14:49:17 CET] <zyme> is it possible to encode to divx's h.263 with ffmpeg using any special compile options for ffmpeg? [14:50:11 CET] <sfan5> doesn't xvid work too if you just set a different fourcc? [14:50:12 CET] <zyme> (since I noticed its not in the list of encoding options avalible in the precompiled downloads linked from the ffmpeg site) [14:50:26 CET] <sfan5> (https://trac.ffmpeg.org/wiki/Encode/MPEG-4) [14:50:28 CET] <furq> yeah xvid and divx should both produce compatible bitstreams [14:50:32 CET] <furq> so it's probably a fourcc thing [14:50:44 CET] <zyme> whats fourcc? [14:51:41 CET] <furq> https://www.fourcc.org/fourcc.php [14:51:47 CET] <sfan5> but i don't see a good reason for restricting yourself to 263 if your hw can do 264 [14:51:56 CET] <furq> yeah [14:52:10 CET] <furq> i wouldn't be surprised if h264 superfast was faster and better quality [14:52:13 CET] <furq> er, x264 [14:52:40 CET] <zyme> (keeping in mind this is a hardware decoder that works with divx h.263 even though it's not supposed to - it just supports h.264..) [14:55:12 CET] <zyme> furq: you were right the first time, x264 is by no means near the only h.264 compliant encoder/decoder. [14:55:42 CET] <zyme> oh, it might be the bases for "superfast" though [14:56:20 CET] <JEEB> zyme: x264 is generally more optimized than libxvid and the internal mpeg4 encoder I bet [14:56:31 CET] <JEEB> and dealing with H.264 HW decoders is much simpler than MPEG-4 Part 2 [14:56:32 CET] <JEEB> trust me [14:57:11 CET] <JEEB> so -c:v libx264 -preset veryfast|superfast -crf 15 -level (4.1|41) [14:57:24 CET] <JEEB> I don't remember which format if not both were accepted [14:57:27 CET] <JEEB> for level [14:57:36 CET] <furq> 41 [15:01:55 CET] <zyme> 4cc is just an identification code? then if two codecs are compatible/compliant then shouldn't you be able to forge (Lie) about what the 4cc is? [15:02:40 CET] <JEEB> but many plastic boxes only support one or two for a specific format [15:02:45 CET] <zyme> If I got that wrong blame the very vague discription on that 4cc url lol. [15:02:49 CET] <DHE> that has happened. MPEG4 (part-2) has several different 4cc that are mostly compatible [15:03:01 CET] <JEEB> yea [15:03:01 CET] <DHE> but only "mostly". there are minor differences that have caused problems [15:03:07 CET] <JEEB> huh [15:03:13 CET] <JEEB> aren't they all mpeg-4 part 2 :P [15:03:23 CET] <DHE> wasn't there some xvid compatibility issues at one point? I could have sworn there was [15:03:33 CET] <JEEB> maybe there were but man that was ages ago [15:03:41 CET] <JEEB> but generally the issue was the fact that many IDs were made up [15:03:49 CET] <JEEB> instead of keeping for a single thing for a format [15:04:08 CET] <JEEB> also AVI was time when each *implementation* used its own four-char identifier [15:04:13 CET] <JEEB> instead of each *format* [15:04:18 CET] <DHE> divx, xvid, fmp4 [15:04:27 CET] <JEEB> so each time a new encoder came onto the scene the clients would have to be updated [15:04:38 CET] <JEEB> whic of course is just wee-wee talk with plastic boxes [15:05:02 CET] <JEEB> although with mpeg-4 part 2 I think that was your smallest problem because the HW decoders didn't genearlly support the default enabled feature set or something [15:05:04 CET] <DHE> or people would fake the ids [15:05:18 CET] <JEEB> and there were no clearly defined compatibility limits [15:05:21 CET] <JEEB> in the HW decoders [15:07:01 CET] <JEEB> while with H.264 the major containers got properly specified identifiers [15:07:26 CET] <zyme> theres already a bunch of "compatible" codecs that are encoded without corruption and are suppedly compliant but always freeze in the same place on my decoder if I don't use software that detects it's error-state and attempts to continue on past that point automaticly at the first working point (other players I just restart, then skip to 30sec/1min after the freeze point manually) - I try to use a different encoding or [15:07:27 CET] <zyme> transcode what I have for my saved files collection to avoid it in the future but still.... [15:08:10 CET] <JEEB> zyme: ouch... and you have no idea where your decoder has a glitch in the H.264 side of things? [15:08:14 CET] <JEEB> or is that MPEG-4 Part 2? [15:12:21 CET] <zyme> It doesn't exactly give much if any error feedback to me, but it was dirt cheap and for a long while I used a server program that did a very simple transcode h264 -> h264 AVC with a couple specified output settings Just-In-Case, and it used less cpu power to stream then to play on a computer [15:13:08 CET] <JEEB> well, yea. I didn't expect it to tell you :) [15:13:23 CET] <JEEB> zyme: but all of those are within some profile/level? [15:14:53 CET] <zyme> it's a tad bit dependent on checking in with the dev's server when it loads and verifying file hash's + latest version / approved usable version - and the latest updates don't work nearly as efficiently (it wants to use much more cpu power on its encode settings then it use to). [15:16:05 CET] <JEEB> uhh, I wasn't talking about the encoder, just the decoder since you started off wanting to encode with libx264 here (and thus feed your plastic box the stream) :) [15:16:58 CET] <zyme> so if I don't notice the quality is less then I like I used that program most the time, if I want to squeeze a little more quality then I play native decoding, if I know from experience the file works with it - or I want to chance it. [15:20:46 CET] <zyme> I slid off subject a bit to explain how I live with such unreliable hardware decoder: a server that does very minor transcoding with nearly impossible to detect degradation from once codec to the same one at a tiny cpu req (say 10% of one of my cores). [15:24:21 CET] <zyme> I should just fix my broken ipad mini and use an hdmi adapter, since its already my remote - but the adapter itself is tons more money then my little plastic unreliable plastic box lol. [15:29:35 CET] <zyme> iPad Story: I dunno if it's fixable though, It got a little water damage a few years ago and recently it started saying my battery was dead whenever the temperature drops below a certain amount. as long as its running and doing something thats usally enough, but if I take it anywhere then sometimes it isn't - so for now the ipad sits next to the cpu fan exhaust on my laptop, and if it ever does the fake dead battery [15:29:36 CET] <zyme> error message thing I hold it in front of the space heater for a couple minutes and it starts right up and reads full battery charge at 85% of its original max capacity. one of these I'll chance taking the screen off and examining it. [15:30:22 CET] <Kam_> Hi, I'm trying to cross-compile (GCC-MinGW64 FreeBSD to Win64) FFmpeg with a very recent git-version and it fails when linking avformat-58.dll with: libavformat/hlsenc.o:hlsenc.c:(.text+0x384): undefined reference to `ff_http_do_new_request'. It works with an older git-version from about begging of November. [15:33:41 CET] <Kadigan> Hey... swscaler is having an issue with me - I'm trying to crop and rescale video, but the video has black/inaccurate boundaries, so I need to cut off a few pixels here and there (4 from the left, 5 from the bottom). I made it 4 and 6, to be 2-divisible... do I need to make the resultant crop 16-divisible? It's barking that "data is not aligned! This can lead to a speedloss" (the vf I'm using is crop=476:354:4:0,scale=640:360,setdar=16:9") [15:34:19 CET] <Kadigan> (yes, I'm trying to fix an improperly compressed video, where a HD source was compressed to 4x3 and resulted in a 'squeezed' picture) [15:36:01 CET] <Kadigan> The closest crop that satisfies /2 and /16 would be 448x336, and I obviously don't want to cut off so much. [15:38:38 CET] <furq> i've always just ignored that message [15:38:59 CET] <Kadigan> It's weird... as soon as I set crop's X to 0, ie. crop=476:354:0:0 [15:39:02 CET] <Kadigan> it stops complaining. [15:39:07 CET] <Kadigan> As soon as it's non-zero, it complains. [15:39:32 CET] <furq> the speed loss won't be measurable compared to encoding anyway [15:39:48 CET] <furq> but iirc crop,copy,scale will silence that warning if x isn't mod16 [15:39:57 CET] <furq> will it make it faster? who knows [15:40:11 CET] <Kadigan> Oh. I did some googling and came to the conclusion that "speedloss" it claimed would be an A/V desync. [15:40:15 CET] <Kadigan> Not an encoding speed loss. [15:40:18 CET] <furq> i only know that because zscale will straight up segfault if x isn't mod 16 [15:41:05 CET] <furq> also that doesn't seem likely but i'm not an swscale developer so listen to someone more qualified if they show up [15:41:08 CET] <Kadigan> The notification is confusing, then. If it said "This can lead to encoding speed loss." from the beginning, I wouldn't have bothered. [15:41:56 CET] <Kadigan> But, as we both know, there's a number of solid ways to screw up the a/v sync... and I didn't want to be on the receiving end of my own ignorance ._. [15:42:49 CET] <furq> i'm pretty sure it's telling you that it can't use SSE2 [15:42:55 CET] <furq> which would mean an encoding speed loss, not a sync problem [15:43:19 CET] <Kadigan> Since it was SD, it was going at a healthy 300fps even then, so I guess I didn't mind. [16:02:36 CET] <Mandevil\splat> Hello... I am using -r option to convert variable framerate video to constant framerate... but nothing is really happening. This is the command line> ffmpeg -i PICT0001.AVI -an -c:v mjpeg -r 50 temp.avi [16:03:10 CET] <Mandevil\splat> Isn't -r supposed to drop/duplicate frames to hit the target fps? [16:04:13 CET] <Kadigan> Mandevil\splat: last time I checked, the only way to reliably convert VFR to CFR is to decompress to an interim uncompressed, and then recompress w/ constant frame rate. [16:04:56 CET] <Kadigan> (had the same issue w/ "Bleach", an action anime that has the talking parts in 15fps, or so) [16:05:15 CET] <Mandevil\splat> Not sure why decompressing achieves anything. [16:06:11 CET] <Kadigan> If I recall, it was so that it decodes the video at a constant rate, producing frames as required. Not sure why it can't be done in one step, I don't recall. [16:06:33 CET] <Mandevil\splat> Hm. [16:06:45 CET] <Kadigan> Maybe you can pipe the output of one into another, I never tried that. [16:06:54 CET] <Mandevil\splat> What should I use as codec to get uncompressed video? [16:07:15 CET] <Kadigan> If memory serves, -f rawvideo (be prepared to handle several GBs of data) [16:07:54 CET] <Mandevil\splat> I'm sure rawvideo doesn't contain any signalling info... [16:08:49 CET] <Kadigan> All I remember (vaguely) is that if you try to do it in one step, you'll end up with a host of problems (stretching/compressing video speed, desync, wrong timestamps etc.) [16:10:02 CET] <sfan5> tried -vf fps=50 ? [16:11:02 CET] <Mandevil\splat> Let me try. [16:11:11 CET] <furq> -r is an alias for -vf fps [16:11:32 CET] <sfan5> makes sense, wasn't sure about that [16:11:36 CET] <Mandevil\splat> Oddly enough, -vf fps=NN actually works! [16:11:45 CET] <furq> fun [16:12:14 CET] <Mandevil\splat> Yes, it does the right job (duplicating frames in my case) [16:12:32 CET] <Kadigan> Hm... Though using videofilters will slow the processing down, I assume. [16:12:42 CET] <Mandevil\splat> My source is rather tiny. [16:12:48 CET] <Mandevil\splat> It's SD DVR recording. [16:12:53 CET] <Kadigan> I guess it's still faster than decoding and encoding. [16:12:54 CET] <Mandevil\splat> Just the DVR is really really crummy. [16:13:29 CET] <Kadigan> I have some 2TB of source material to fix VFR in. I never really ended bothering, since I can't be sure it'll work always, and I don't have the time to watch every single output before committing to storage. And I don't have 2TB around to keep both versions until I do. [16:14:49 CET] <Mandevil\splat> Why does anyone use VFR anyway? [16:14:53 CET] <Kadigan> (and yes, I do have a proper reason - using something called SVP, which tweens frames up to screen speed w/ smooth motion - it expects a smooth stream, changing framerates discards the buffer which results in a 2-3s delay in playback, and it's annoying if it happens every few seconds) [16:15:05 CET] <Mandevil\splat> If there's nothing changing in the image, the codes will squash it anyway. [16:15:12 CET] <Mandevil\splat> codec [16:15:28 CET] <Kadigan> Assuming it will. [16:15:34 CET] <sfan5> not necessarily [16:16:05 CET] <Kadigan> It may also not be strictly required. If the source material is VFR, and the encoding <can> do VFR, and the player also <can> play VFR, why go to the trouble of making it CFR? [16:16:16 CET] <sfan5> (keyframes, ref limits) [16:16:37 CET] <Kadigan> In most cases it's not an issue, and professional editors will deal with it anyway. [16:16:47 CET] <Kadigan> Or should, in theory. [16:17:05 CET] <Kadigan> So you only see issues when you're doing stream processing that expects a smooth stream, like in my case. Or in yours, I don't know. [16:17:48 CET] <Kadigan> In my case it works perfectly well, only there's a delay because the expectation is for it to be real-time - an assumption that isn't necessarily true in playback. [16:18:24 CET] <Mandevil\splat> Kadigan: The problem is that my source _claims_ it is 25 fps, but in reality it varies around 17-16 fps. [16:18:36 CET] <Mandevil\splat> Kadigan: And that causes desync in editor. [16:18:36 CET] <Kadigan> If I recall, FPS is ever only estimated. [16:19:09 CET] <Kadigan> (in fact, if SVP could be "fixed" to account for VFR by some look-ahead that'd preallocate the buffers as required for a smooth transition, I wouldn't <need> to recode my VFR sources) [17:38:31 CET] <Tatsh> really like these filters my GPU can do [17:38:32 CET] <Tatsh> --vf=vdpaupp:denoise=1:hqscaling=1:deint=yes:deint-mode=first-field:denoise=1:pullup [17:38:39 CET] <Tatsh> this is for mpv; how can i pass these into ffmpeg? [17:41:11 CET] <BtbN> I don't know of any vdpaupp in ffmpeg. [17:45:26 CET] <furq> isn't that an mpv thing [18:12:41 CET] <neverminder> Hi, I'm trying to record both video and audio simultaneously, but it doesn't work [18:13:19 CET] <neverminder> This is the closest I've got so far that doesn't throw any errors: ffmpeg -f v4l2 -input_format mjpeg -s uhd2160 -i /dev/video0 -f pulse -channels 1 -i default video.mp4 [18:14:30 CET] <neverminder> output gets stuck on frame 1 and produces 0 bytes file: https://pastebin.com/uW7jL7EB [18:17:37 CET] <TAFB> can anyone help me get my ip 4k30 camera working smooth plz? https://www.youtube.com/c/Skyviewelectronics/live and the puter specs http://tafb.xxx/4k_stream_puter.png and the ffmpeg command https://pastebin.com/GdNL7tcw [18:17:59 CET] <TAFB> camera is perfectly smooth if I play it in vlc or internet explorer :( [18:20:24 CET] <JEEB> 1) the ID is shown in the screenshot 2) just for reference you can stop using 44.1kHz and LAME for audio (-c:a aac -b:a 128k should be enough with any recent FFmpeg) 3) try writing into a file first [18:20:38 CET] <JEEB> also you only set bufsize but not maxrate? [18:21:03 CET] <JEEB> into a file like test.flv instead of rtmp://... [18:21:09 CET] <JEEB> then try playing that FLV file [18:21:26 CET] <JEEB> it really sounds though that you are not getting nice timestamps from the input [18:21:31 CET] <JEEB> and decoding that input fixes that [18:21:40 CET] <JEEB> (because teh decoder handles all the re-ordering etc) [18:21:41 CET] <TAFB> JEEB, the stream has no audio, but if I try and live stream it without audio it stops after a few seconds [18:21:54 CET] <JEEB> no, I mean you don't need to specify 44.1kHz and MP3 [18:22:03 CET] <JEEB> if you use AAC you can use any audio rate [18:22:08 CET] <JEEB> that's in the FLV specs :P [18:22:25 CET] <JEEB> the FLV specs say that for AAC any player should just trust the AAC headers [18:22:45 CET] <JEEB> and that 44.1kHz should be written as a placeholder. this was implemented in FFmpeg in like 2011 or 2012 or so [18:23:05 CET] <JEEB> but yea, your real problem might be with -c:v copy not getting proper timestamps with rtsp [18:23:18 CET] <JEEB> which then passing those packets into a decoder (like playback) fixes [18:23:31 CET] <TAFB> no doubt timestamps are a mess [18:23:32 CET] <JEEB> I've had issues with that with both raw H.264 input as well as MPEG-TS [18:23:42 CET] <TAFB> how can I make FFMPEG do a big bugger and spit out the frames at a perfect 30fps? [18:23:49 CET] <TAFB> big buffer [18:23:57 CET] <JEEB> uhh [18:24:02 CET] <JEEB> you're thinking of a different thing [18:24:10 CET] <TAFB> mjpeg? [18:24:14 CET] <TAFB> f'ing loved mjpeg :( [18:24:43 CET] <furq> for starters, you probably want to get rid of -re [18:24:54 CET] <JEEB> and that too. it's a hack for non-realtime inputs [18:25:08 CET] <JEEB> for an rtsp stream not really required [18:25:10 CET] <TAFB> if I get rid of -re then youtube stops live streaming after a second or two (I assume from the huge flood of frames it gets at the start) [18:25:13 CET] <JEEB> unless you hit a bug with EOF [18:25:25 CET] <JEEB> uhh, your input is realtime so how would that heppen? [18:25:35 CET] <JEEB> although borked timestamps from the rtsp input can do a lot of stuff :P [18:25:55 CET] <JEEB> TAFB: please output some of that stuff into a file first to see how fucked up the thing is [18:25:57 CET] <TAFB> always when I start ffmpeg without -re it always starts around 120fps and trickles down to 30fps [18:26:07 CET] <furq> i take it you can't just force the input framerate with rtsp [18:26:20 CET] <TAFB> JEEB: okies, will do, without -re, just raw, and post up a file, 1 sec. [18:26:29 CET] <TAFB> mp4 or flv? [18:26:32 CET] <JEEB> flv [18:26:37 CET] <JEEB> since that's what RTMP contains [18:27:01 CET] <SortaCore> Is there a way to use Unicode paths in file outputs? [18:27:02 CET] <JEEB> TAFB: the "high" frame rate at first is just how it looks basically since ffmpeg.c buffers the input for a while so it can probe its contents [18:27:12 CET] <TAFB> I have to use "-rtsp_transport tcp" otherwise it's a complete mess, 1 sec. [18:27:26 CET] <JEEB> that is due to your internal network most likely [18:27:36 CET] <JEEB> the default is UDP [18:27:49 CET] <JEEB> and UDP RTSP/multicast is often hated by routers :P [18:29:13 CET] <TAFB> 60 seconds of video good? [18:29:32 CET] <JEEB> should be a plenty. also you should check how that plays yourself first [18:29:42 CET] <TAFB> will do [18:29:45 CET] <JEEB> also I recommend utilizing -v verbose -debug_ts with ffmpeg [18:29:47 CET] <JEEB> for additional information [18:30:13 CET] <JEEB> if you're on windows you can also write stderr into a file with 2> stderr.log or so [18:33:06 CET] <neverminder> Can ffmpeg record video and audio simultaneously or only one at the time? [18:33:17 CET] <TAFB> neverminder: it for sure can [18:33:24 CET] <JEEB> it can have N inputs but synchronizing them can be "fun" [18:33:44 CET] <JEEB> unless the inputs have some sort of timestamps on the same time base [18:34:39 CET] <neverminder> TAFB - Any idea why this doesn't work? ffmpeg -f v4l2 -input_format mjpeg -s uhd2160 -i /dev/video0 -f pulse -channels 1 -i default video.mp4 [18:35:03 CET] <JEEB> neverminder: you get nothing on the logs with -v verbose or -v debug with -debug_ts ? [18:35:23 CET] <JEEB> verbose gives you some things, debug_ts shows you the exact timestamps ffmpeg.c passed around [18:35:33 CET] <JEEB> and debug is "enable really verbose stuff everywhere" [18:35:54 CET] <JEEB> neverminder: also I bet a person on windows doesn't hav too many ideas on v4l2 or pulse :) [18:37:04 CET] <JEEB> TAFB: anyways most likely your issue with -c:v copy is basically lack of timestamps which should come apparent with -v verbose -debug_ts. libavformat has an issue with calculating/fixing timestamps from containers/protocols that don't really have them [18:37:11 CET] <neverminder> JEEB - this is the output I get with -v verbose: https://pastebin.com/5hHKvULP [18:37:13 CET] <JEEB> and people generally don't notice because they decode the input [18:37:18 CET] <TAFB> JEEB: files uploading now, 1 sec . [18:37:20 CET] <neverminder> gets stuck and frame 1 and no idea why [18:37:32 CET] <JEEB> TAFB: have you tried playing the file with mpv or vlc? [18:37:42 CET] <JEEB> windows builds for mpv can be found @ https://mpv.srsfckn.biz/ [18:37:43 CET] <TAFB> cpu isn't even close to fast enough to encode 4k live, so -c copy will have to do [18:37:53 CET] <JEEB> well yea, I'm not recommending you do that [18:37:59 CET] <JEEB> I'm just saying where I'm feeling the issue might be at :P [18:38:41 CET] <JEEB> because I've had similar issues trying to -c:v copy H.264 from MPEG-TS to MPEG-TS [18:39:42 CET] <JEEB> neverminder: up to that point that looks OK as far as the logs go :P [18:40:57 CET] <neverminder> JEEB - just ran it with -v debug and it's a mess: https://pastebin.com/GqkVR7ZH [18:41:22 CET] <JEEB> oh yes, debug_ts might be more useful there :P [18:41:31 CET] <neverminder> What does "cur_dts is invalid (this is harmless if it occurs once at the start per stream)" mean? [18:41:32 CET] <JEEB> but yes, you can clearly see it's not happy with the timestamps it's getting [18:41:41 CET] <TAFB> JEEB: http://tafb.xxx/test.flv and http://tafb.xxx/test.txt :) I'm downloading them now to try and play them (they are captured on a remote machine). [18:43:17 CET] <TAFB> plays a little strange [18:43:56 CET] <JEEB> I bet it plays a little strange [18:44:53 CET] <JEEB> you can just look at those -debug_ts outputs [18:45:12 CET] <TAFB> the "[flv @ 000001e1f618c020] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly" line? :) [18:45:23 CET] <JEEB> that was visible before, too - and gave you some hints :) [18:45:33 CET] <TAFB> so here's my thinking [18:45:48 CET] <JEEB> "demuxer -> " is what lavf read, demuxer+ffmpeg is after ffmpeg.c mucks with the timestamps [18:45:58 CET] <TAFB> can FFMPEG not make it's own timestamps? Just make a big 10 second buffer, as complete frames arrive, stamp them, spit them out at a flawless 30fps [18:46:00 CET] <TAFB> no!? [18:46:41 CET] <JEEB> not sure if there's code for that - a lot of those solutions have been focused around video filters which of course you can't run on non-raw things :D [18:46:51 CET] <JEEB> and "muxer <- " is what gets fed into the FLV muxer [18:47:40 CET] <JEEB> so the first feed is NOPTS/0, then you have 0/0, 54/54 [18:48:41 CET] <JEEB> for for straight 30fps that'd be +33 for each picture if there are no B-frame shenanigans [18:48:58 CET] <JEEB> (b-frames can make the presentation time stamp go out of order) [18:49:52 CET] <TAFB> when I search on re-writing timestamps without re-encoding it looks like mp4box can do it. Question is can it do it live :) [18:50:09 CET] <JEEB> nah, you can't just stick it into ffmpeg [18:50:27 CET] <JEEB> also nothing stops from ffmpeg.c from doing it, the thing's just not there yet [18:50:37 CET] <JEEB> I'm more interested in WTF are these timestamps and how did they end up like that :P [18:51:11 CET] <TAFB> no-name chinese ip camera that their techs thought could "improve" h264 implementation no doubt [18:51:27 CET] <JEEB> nah, I wouldn't even put blame there yet [18:51:45 CET] <JEEB> 'cause I know we have issues with things that don't give Really Nice timestamps [18:52:00 CET] <JEEB> such as raw H.264 or MPEG-TS [18:52:03 CET] <JEEB> as just some examples [18:52:11 CET] <JEEB> (which I have felt on my own skin) [18:52:50 CET] <JEEB> anyways, some timestamps are generated as you can see from the muxer <- lines [18:52:57 CET] <JEEB> that's what ends up being fed to the FLV muxer [18:53:19 CET] <furq> you might actually be able to do it in a really awful hacky way [18:53:22 CET] <JEEB> also is this camera supposed to be CFR or VFR [18:53:48 CET] <JEEB> this jump from 3000 (still looks OK) to 7900 is weird [18:53:51 CET] <furq> ffmpeg -i rtsp://... -c copy -f h264 - | ffmpeg -f h264 -r 30 -i - -c copy rtmp://... [18:53:58 CET] <JEEB> :D [18:54:05 CET] <furq> i warned you [18:54:26 CET] <TAFB> I can make it CFR or VFR [18:55:58 CET] <TAFB> furq: I'll give it a try, so first ffmpeg streaming it as udp:127.0.0.1:1234 and the second ffmpeg -i the udp? [19:00:07 CET] <JEEB> no, it's just output into stdout [19:00:12 CET] <JEEB> and the second reads from the stdin [19:00:14 CET] <JEEB> piping [19:00:20 CET] <TAFB> on windows? [19:00:24 CET] <JEEB> works fine [19:00:32 CET] <TAFB> never knew that :) [19:00:32 CET] <JEEB> unless in powershell, that one tries to buffer the stdout [19:00:58 CET] <TAFB> i always run two (or more) copies of ffmpeg and use udp 127.0.0.1 to send it between [19:00:59 CET] <TAFB> 1 sec. [19:02:25 CET] <JEEB> furq: also I remember that if you have b-frames the h264 demuxer doesn't calculate the timestamps right [19:02:30 CET] <ayum> Hi, I have a question above ffmpeg auto inserted scaler, my input is 1280x720 uyvy422 format, it was scaled to 1280x720 yuv420p format. does it will lost quality in this scaler? [19:02:50 CET] <JEEB> yes, you lose chroma [19:02:55 CET] <JEEB> 4:2:2 to 4:2:0 [19:03:16 CET] <ayum> I only used Y plane, so lost chroma plane is okay [19:03:17 CET] <JEEB> but often if you f.ex. are encoding H.264 the default is 4:2:0 because that's most supported in hw decoding etc [19:09:29 CET] <TAFB> furq: https://pastebin.com/eSjEvsTb [19:10:10 CET] <JEEB> yea, you left -f flv out [19:10:16 CET] <JEEB> which for some reason is still needed for the protocl [19:10:25 CET] <TAFB> ahh [19:11:59 CET] <TAFB> ok, show's it streaming but "stream health" is red in live youtube list [19:13:29 CET] <TAFB> i'll try writing output to file and see how it looks [19:13:43 CET] <JEEB> debug_ts should tell you a lot to be honest [19:13:54 CET] <JEEB> since it tells you a lot about what gets fed into the muxer [19:16:46 CET] <TAFB> http://tafb.xxx/test2.flv [19:16:49 CET] <TAFB> haven't seen it yet [19:17:29 CET] <TAFB> OMG! [19:17:32 CET] <TAFB> IT'S PERFECTLY SMOOTH! [19:17:34 CET] <TAFB> woot :) [19:18:18 CET] <TAFB> vlc says framerate is 1000fps :) [19:19:58 CET] <JEEB> yea that's the time base for FLV [19:20:15 CET] <JEEB> FLV stores time stamps with a 1/1000 time base [19:20:25 CET] <JEEB> so in a way it's correct ;) [19:20:36 CET] <JEEB> and yes, that also means that a lot of frame rates will not be exact in FLV [19:21:15 CET] <TAFB> alright, so just have to figure out why youtube isn't liking it [19:21:32 CET] <JEEB> possibly it isn't according to their buffering standards if they're passing it through as-is [19:21:51 CET] <TAFB> i bet if we through an audio stream in with it, it'll take it [19:22:10 CET] <JEEB> your guess is as good as mine :) [19:22:23 CET] <furq> yeah you need a blank audio stream for youtube [19:22:33 CET] <JEEB> anyways too bad so many services have built workflows around FLV [19:22:38 CET] <JEEB> since FLV is now dead [19:22:44 CET] <JEEB> and will most likely not get expanded [19:22:50 CET] <JEEB> so HEVC, VP9, AV1... [19:22:58 CET] <TAFB> furq: could you help me with what/where to put the audio into that command you gave me!? :) [19:23:12 CET] <JEEB> just add the audio filter thing you had in the first one [19:23:17 CET] <furq> add it to the right hand side of the pipe [19:23:19 CET] <JEEB> to the second ffmpeg [19:23:24 CET] <furq> yeah [19:23:40 CET] <TAFB> k. [19:24:16 CET] <furq> just -f lavfi -i anullsrc -c:a aac -c:v copy [19:24:17 CET] <furq> should be fine [19:24:27 CET] <TAFB> k. [19:25:00 CET] <JEEB> also -b:a 96k to just set some bit rate :) [19:25:08 CET] <furq> it'll default to 128k iirc [19:25:08 CET] <JEEB> (heck you could even go lower) [19:25:25 CET] <furq> and this is a copied 4k iptv stream so i'm guessing bandwidth isn't an issue [19:25:48 CET] <SortaCore> rip my question [19:25:55 CET] <SortaCore> buried alive at such a young age [19:26:05 CET] <furq> why wouldn't you be able to use unicode paths [19:26:15 CET] <JEEB> SortaCore: unicode paths should work just fine [19:26:23 CET] <furq> if it's not working it's probably your shell [19:26:50 CET] <JEEB> I don't remember how it worked with the API exactly, but as far as I can tell the cli can take in windows wide char paths just fine [19:26:59 CET] <JEEB> API might require utf8 renditions [19:27:04 CET] <JEEB> which it would then convert to wide char internally [19:27:10 CET] <JEEB> for windows file access APIs [19:27:30 CET] <SortaCore> avio_open2 takes a const char * [19:27:41 CET] <SortaCore> utf8 * was a C++14 thing or something [19:28:24 CET] <JEEB> nah, UTF-8 is usually passed as char * [19:28:34 CET] <JEEB> wchar is something most people dislike [19:28:53 CET] <TAFB> aac stream of 2kbps works, 1kbps didn't :) [19:28:55 CET] <JEEB> but I will have to double check but I /think/ the API wants UTF-8 [19:28:59 CET] <SortaCore> u8"txt" [19:29:11 CET] <SortaCore> well, there's nothing in avio_open2 comments about UTF-8 [19:29:22 CET] <JEEB> yea, trying to check the docs [19:29:41 CET] <JEEB> because other API-using apps are handling it and I know we have internal code for handling windows unicode paths [19:29:55 CET] <JEEB> have you tried using wchar to utf8 functions in windows and just passing the string? [19:30:05 CET] <SortaCore> looks like my code does do WCHAR -> UTF8 anyway [19:30:12 CET] <JEEB> because I bet testing it out like that should JustWork [19:30:22 CET] <SortaCore> I'll try some weeb kanji [19:30:23 CET] <JEEB> (or not and then we're a bit wiser [19:31:33 CET] <JEEB> SortaCore: yea just git grep -i "utf-8" [19:31:45 CET] <JEEB> and cmdutils.c does wchar->utf8 [19:32:03 CET] <JEEB> so I bet the API always requires UTF-8 but then internally does the additional stuff to make it work on windows [19:32:11 CET] <JEEB> (UTF-8 back to wchar) [19:32:18 CET] <JEEB> just to keep the interface the same between OSs [19:32:25 CET] <JEEB> (also fuck wchar <3) [19:33:41 CET] <SortaCore> WCHAR was doomed from the start [19:34:03 CET] <SortaCore> I wonder who had the bright idea "1 byte char ain't big enough... let's do 2 byte, that'll definitely be future compatible" [19:34:36 CET] <JEEB> I think at this point it's actually variable length in the end [19:34:45 CET] <JEEB> since it has to support things that don't fit into 2 bytes [19:35:02 CET] <SortaCore> yea, but that's even more confusing [19:35:10 CET] <JEEB> yup [19:35:23 CET] <SortaCore> since sizeof(char_type) is what most people are used to [19:35:29 CET] <JEEB> yup [19:35:32 CET] <SortaCore> then there's that multibyte weirdness [19:36:16 CET] <SortaCore> strlen, wcslen, _mbslen :p [19:36:23 CET] <SortaCore> then the TCHAR usefulness [19:36:38 CET] <JEEB> oh yea [19:36:45 CET] <JEEB> because non-unicode builds are still a thing you totally want [19:36:52 CET] <JEEB> _T("perkele") [19:37:22 CET] <SortaCore> I'm writing a DLL for some software dated back to 90s [19:37:33 CET] <SortaCore> it has unicode and non-unicode [19:37:40 CET] <JEEB> rip [19:38:02 CET] <JEEB> reminds me of a company trying to recruit people at the mixed Qtcon/VDD [19:38:04 CET] <SortaCore> it is slightly odd to me there's no std::tstring or std::tstringstream from MS [19:38:39 CET] <JEEB> on the top of the recruitment thing they had "we need best C++ devs" which is generic as usual [19:38:39 CET] <SortaCore> fortunately, the software will be getting a new codebase on next iteration [19:39:00 CET] <SortaCore> I'm a C++ dev, but I oddly don't do anything like the new C++ [19:39:10 CET] <JEEB> but then if you actually opened the leaflet they talked about using IDA Pro to reverse engineer MS Office and doing runtime patching of the binaries [19:39:26 CET] <SortaCore> the closest I get is lambdas [19:39:28 CET] <JEEB> just so people can get powerpoint plugins that utilize private features <3 [19:39:40 CET] <SortaCore> that sounds... really confused [19:39:51 CET] <SortaCore> but hey, if it works [19:39:56 CET] <JEEB> yea [19:40:01 CET] <SortaCore> DLL injection ftw right [19:40:04 CET] <JEEB> and deffo it sounds different to just coding off C++ [19:40:25 CET] <JEEB> and actually admitting to RE is cool, since clean-room RE is fine [19:40:43 CET] <JEEB> not that I necessarily want to end up doing something like that, but at least it stuck in my mind [19:40:49 CET] <SortaCore> I've not done that, although the SDK was released with a ton more code than actually needed [19:41:05 CET] <SortaCore> someone did create a new version of the software with the SDK though [19:41:15 CET] <SortaCore> and it ended up a ton faster [19:41:24 CET] <SortaCore> probably what kick-started a new iteration [19:42:06 CET] <SortaCore> the thing is, I'm used to C#, where templates are very easy [19:42:13 CET] <SortaCore> in C++ I get told all sorts of odd errors [19:42:34 CET] <SortaCore> I used __asm int 3; in a define once and it started fussing about braces everywhere [19:43:40 CET] <SortaCore> it's the equivalent of "debug break and get a debugger if there isn't one" [19:44:34 CET] <JEEB> yea, I really know the limits of C but I'm not someone who'd be too happy of going into C++ [19:44:46 CET] <JEEB> or not know, but I acknowledge that some crap is just really bad in C [19:45:01 CET] <JEEB> and that the language misses a lot of helper stuff you need in everyday life [19:45:16 CET] <SortaCore> yea, then you feel like you shouldn't add it because it'll Make It Slower [19:45:25 CET] <SortaCore> and introduce more points of failure [19:45:46 CET] <JEEB> also not everyone minds the differences of C and C++ [19:45:54 CET] <JEEB> like checking the result of new [19:45:56 CET] <JEEB> for nullptr [19:46:21 CET] <SortaCore> you can replace that with a throw... but either case still looks odd [19:46:32 CET] <JEEB> and because of being a C person instead of try/catching that I instead just added std::nothrow [19:46:36 CET] <JEEB> :D [19:46:52 CET] <JEEB> and suddenly the code worked because the rest of it expected a nullptr in case of failure [19:47:02 CET] <neverminder> Any ffmpeg developers here that could help me understand what the problem is? [19:47:06 CET] <SortaCore> heh, not the worst thing I've done [19:47:25 CET] <JEEB> neverminder: I couldn't see anything specifically wrong with your logs [19:47:44 CET] <SortaCore> mapping? [19:48:02 CET] <neverminder> JEEB - this is the last one, all possible debugging enabled: https://pastebin.com/qiyR15Dn [19:48:03 CET] <SortaCore> oh nvm [19:48:49 CET] <neverminder> What does "cur_dts is invalid (this is harmless if it occurs once at the start per stream)" mean? It repeats in some kind of a loop and this is where things get stuck... [19:49:48 CET] <rajkosto> how can you guarantee lowest decode latency using the ffmpeg api (h264) ? it seems that it prefers to lag by one or two pictures even though it has all the data to decode it [19:51:10 CET] <rajkosto> adding a null input packet sometimes gets the picture out, i'd rather not have to do this [19:54:33 CET] <JEEB> rajkosto: the decoder in theory should require the minimum amount of latency. sometimes there's latency because of b-frame reordering etc. also are you using the old API or the new push/pull API? [19:54:50 CET] <JEEB> this is the new one https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [19:55:28 CET] <rajkosto> just old avcodec_decode_video2 [19:55:45 CET] <JEEB> yea, that might have its overhead [19:56:05 CET] <rajkosto> basically, i want pure software, single threaded, whatever it takes, i just want to have a frame immediately after i feed it enough NALs for one [19:56:05 CET] <JEEB> please quickly test the "new" one (it's over a year old by now IIRC) [19:56:45 CET] <rajkosto> i dont care if it gives me frames "out of order" since i already tag input avpackets with timestamps [19:56:45 CET] <JEEB> yea, if you set threads to 1 or use slice threading you should get it as soon as possible with regards to b-frames [19:57:48 CET] <JEEB> yea I think I'm not sure if you can disable that functionality [19:58:05 CET] <rajkosto> i think it wants to reorder them itself [19:58:10 CET] <JEEB> yes [19:58:15 CET] <JEEB> but only if you have b-frames anyways [19:58:24 CET] <rajkosto> https://pastebin.com/mX5qZyDN [19:58:27 CET] <JEEB> I would first of all recommend you to poke the send/receive API [19:59:06 CET] <JEEB> yea, that should have threads at 1 [19:59:15 CET] <JEEB> also why disabling refcount? [19:59:20 CET] <JEEB> I don't think that adds any latency [19:59:34 CET] <rajkosto> i dont need it, and i think its only used for threaded decode [19:59:50 CET] <JEEB> nah, it is refcounting of the things so unnecessary memcpys are reduced [19:59:56 CET] <JEEB> it doesn't really have anything to do with threads [20:00:47 CET] <rajkosto> what ffmpeg do i need for this new method to work [20:00:56 CET] <JEEB> it's pretty old by now [20:01:05 CET] <JEEB> let me see if we have it in the API change logs [20:01:54 CET] <JEEB> http://up-cat.net/p/66f847cc [20:02:02 CET] <JEEB> so any release branched after that [20:03:14 CET] <JEEB> apparently 3.1 was the first release branch to be cut after that [20:03:28 CET] <JEEB> although I definitely recommend generally working with the latest HEAD after making sure FATE passes [20:03:35 CET] <rajkosto> https://pastebin.com/VZxHLU00 [20:03:46 CET] <rajkosto> whatever that means, overall version just says 3.2-git [20:04:17 CET] <JEEB> yea, that means it's a pretty old HEAD version [20:04:21 CET] <JEEB> from after 3.1 [20:04:24 CET] <JEEB> so you have the APIs [20:05:02 CET] <rajkosto> At the beginning of decoding or encoding, the codec might accept multiple input frames/packets without returning a frame, until its internal buffers are filled. This situation is handled transparently if you follow the steps outlined above. [20:05:13 CET] <rajkosto> i dont want any buffering more than the minimum [20:05:46 CET] <JEEB> yes, that is what is meant [20:06:03 CET] <JEEB> if you have packets with parameter sets etc it will of course eat those, same for non-IRAP pictures [20:06:11 CET] <JEEB> so if it cannot output a picture it will not output a picture :P [20:06:22 CET] <JEEB> for the reordering there's not much you can do with that can you? [20:06:47 CET] <JEEB> because you will have to reorder them yourself anyways [20:07:00 CET] <JEEB> so I don't see that as any sort of latency that you can avoid [20:07:24 CET] <JEEB> if your stream doesn't require any reordering according to the parameter sets then it should just output them [20:07:35 CET] <JEEB> (or according to the stream itself) [20:08:37 CET] <JEEB> so the expectation is that with the send/receive API you should be able to read a picture as soon as it is technically possible to get it in the correct presentation order [20:09:30 CET] <JEEB> if the results are not what is expected then that is either an issue with the stream or a bug in FFmpeg's decoder [20:24:25 CET] <rajkosto> ah [20:24:34 CET] <rajkosto> but i always feed it enough NALs for a new picture [20:24:44 CET] <rajkosto> and i want to get that picture in decoding order since i already tagged it with a timestamp in the avpacket [20:24:49 CET] <rajkosto> as soon as possible [20:25:04 CET] <rajkosto> the reordering is done in a different place, i just need to fill gpu buffers [20:25:15 CET] <rajkosto> and i get a lag of a couple of frames whne using ffmpeg [20:27:54 CET] <JEEB> yea that doesn't help since the decoder is built for reordering to be done there. since when you reorder you're getting latency anyways - it just gets moved to another spot [20:28:05 CET] <rajkosto> thats fine, i have an interface to conform to [20:28:16 CET] <rajkosto> it performs reordering later on [20:28:27 CET] <JEEB> that said we still haven't figured if that's the thing or not that you're having an issue with :P [20:28:37 CET] <JEEB> which is why I asked you to move to the send/receive API [20:28:43 CET] <rajkosto> this means that using ffmpeg instead of the original hardware decoder breaks some applications that expect frames immedaitely [20:29:10 CET] <JEEB> yes, that would be correct then [20:29:16 CET] <JEEB> IFF that is the problem [20:29:18 CET] <rajkosto> i doubt that moving to the new interface would change anything [20:29:35 CET] <JEEB> yea I'm just trying to ensure that the frame reordering delay is what your issue is [20:30:35 CET] <rajkosto> when is the decoding actually performed ? when i give it nals or when i try to get pictures out [20:30:47 CET] <rajkosto> since i disabled threading it has to be done at one place or the other [20:31:27 CET] <JEEB> when you send it a packet it will call decode_frame() most likely [20:32:27 CET] <JEEB> then the decode framework has a list of available AVFrames which can have a length of 0 or more [20:32:36 CET] <JEEB> when you try calling the receive one [20:33:09 CET] <rajkosto> i wonder if AV_CODEC_FLAG_TRUNCATED and AV_CODEC_FLAG2_CHUNKS are doing anything useful [20:33:13 CET] <JEEB> no [20:33:16 CET] <JEEB> they are not [20:33:25 CET] <rajkosto> pretty sure i need chunks if i was to feed it one NAL at a time [20:33:48 CET] <JEEB> nope, as far as I can tell most demuxers feed it separate NALs :P [20:33:49 CET] <rajkosto> thats why i added it [20:33:56 CET] <rajkosto> i mean for the old interface [20:35:25 CET] <JEEB> rajkosto: I'm pretty sure even without that flag and even with the old interface you just wouldn't get a decoded frame [20:35:37 CET] <JEEB> until you fed all the NAL units for a single picture [20:35:45 CET] <JEEB> *required for a single picture [20:36:02 CET] <rajkosto> theres a reason i added it, i think it was erroring without it when i was feeding single nals [20:36:42 CET] <JEEB> just never seen that one and I'm not 100% sure what it means in this context. but sure, it's possible that the decoder would require all NALs that are a decode'able picture [20:36:47 CET] <JEEB> although that would be surprising to be honest :/ [20:37:13 CET] <JEEB> maybe lavf was making it nice and simple for me :P although I do remember it outputting all the parameter sets in separate AVPackets first [20:37:53 CET] <JEEB> rajkosto: and teh reason why pushing a NULL there probably "worked" was because that started the flushing procedure [20:38:02 CET] <JEEB> "end of stream, output what is still in the buffers" [20:38:08 CET] <JEEB> if buf_size == 0 [20:38:11 CET] <rajkosto> yep, thats how i was able to get single frames out immediately [20:38:20 CET] <rajkosto> but only sometimes, othertimes it would actualyl give me bad frames out [20:39:55 CET] <JEEB> but yea, flushing the decoder requires its own resets etc so it is quite likely to break (or already is breaking) [20:40:13 CET] <JEEB> so if you need the pictures output without reordering I think unfortunately libavcodec is not for you [20:40:29 CET] <JEEB> or if you make a patch for that and if it gets accepted that's a possibility [20:40:45 CET] <rajkosto> what if you need to send out the frames somewhere else immediately, not just for display [20:41:10 CET] <JEEB> well transcoding also needs the pictures in correct order for motion estimation etc to work [20:41:33 CET] <JEEB> so it's very limited what gets a benefit from not reordering the pictures correctly [20:41:47 CET] <CoreX> bugting [20:41:50 CET] <CoreX> bufting* [20:41:53 CET] <JEEB> or at least that's how I see it, maybe there are reasons for it beyond "some HW just wants stuff asap" [20:42:22 CET] <rajkosto> there should be a flag for it [20:42:38 CET] <JEEB> I don't disagree, but there currently isn't such in the H.264 decoder [20:42:51 CET] <JEEB> I mean, I don't see the use case but I don't disagree for a flag like that :P [20:44:53 CET] <rajkosto> its because i only get limited chances to fill gpu buffers and i miss them because ffmpeg is keeping frames from me [20:45:56 CET] <JEEB> you might want to post about that either on the trac issue tracker or ffmpeg-devel mailing list as a feature request then [20:47:29 CET] <JEEB> there's already a flag (AV_CODEC_FLAG_LOW_DELAY) [20:47:49 CET] <JEEB> it seems like the mpeg-2 and mpeg-4 part 2 decoders follow that in some way [20:48:00 CET] <JEEB> but I don't see references in the H.264 one [20:48:49 CET] <JEEB> if it does the same thing in mpeg-2 or mpeg-4 part 2 then it might make sense to request for that to be added to H.264 as well [20:51:21 CET] <rajkosto> Note that the function will always call [20:51:21 CET] <rajkosto> *av_frame_unref(frame) before doing anything else. [20:51:23 CET] <rajkosto> what does that mean [20:51:29 CET] <rajkosto> do i need to unref it or not [20:52:42 CET] <JEEB> it sounds like if you still have a reference to the AVFrame it will unref it when you feed it to the decoder to get a new set of data [20:53:26 CET] <rajkosto> so if im reusing the same one i dont manually unref it, except at the end when im destroying it anyway [20:55:01 CET] <JEEB> I'm not 100% right but that sounds about right if I read that documentation correctly. [20:57:20 CET] <rajkosto> it seems that for mpeg4 AV_CODEC_FLAG_LOW_DELAY is only able to be set if the stream doesnt have b frames [20:58:45 CET] <JEEB> hmm, not exactly [20:59:02 CET] <JEEB> or wait [20:59:19 CET] <rajkosto> because it sets has_b_frames to its opposite [20:59:50 CET] <JEEB> yea the has_b_frames is generally utilized as an internal thing in the decoders [20:59:54 CET] <JEEB> as a reorder amount etc [21:00:07 CET] <JEEB> so if you set low_delay =1 then has_b_frames goes to zero [21:00:10 CET] <JEEB> and thus zero reorder [21:00:53 CET] <rajkosto> but doesnt it need to know that the stream has b_frames otherwise it wont be able to keep frame history properly ? [21:01:07 CET] <JEEB> well if you want to ignore the reorder then you just force it to zero [21:01:12 CET] <JEEB> which is what that seems to be doing :P [21:01:26 CET] <JEEB> at least that's how it looks to me in the mpeg4 decoder [21:01:32 CET] <JEEB> which is not the H.264 one [21:08:20 CET] <JEEB> rajkosto: but yea, either make a patch yourself or request the feature on trac issue tracker / ffmpeg-devel ML [21:08:57 CET] <durandal_1707> carl doesnt like feature requests on devel ml? [21:09:05 CET] <JEEB> ok, just trac then [21:09:17 CET] <furq> is there anything carl does like [21:09:32 CET] <rajkosto> the cisco h264 decoder doesnt have this problem then again it only supports baseline profile :P [21:10:30 CET] <JEEB> well yes [21:10:40 CET] <JEEB> but on the other hand if you have no reorder requirement in sPS [21:10:46 CET] <JEEB> it shouldn't buffer [21:10:54 CET] <rajkosto> sometimes i do [21:11:12 CET] <JEEB> well yea, then cisco's decoder wouldn't help you would it [21:11:24 CET] <BtbN> How would you not want the re-ordering to happen? [21:11:30 CET] <BtbN> A decoder seems pretty useless without it. [21:11:49 CET] <rajkosto> BtbN, each avpacket has a timestamp field on it anyway, which is replicated in the avframe [21:12:12 CET] <BtbN> But if you re-order them yourself, you'll inevitably re-introduce the exact same delay [21:12:16 CET] <rajkosto> i want the decoder to just return frames even if it doesnt have the next one in presentation order [21:12:18 CET] <teratorn> on a different timescale [21:12:28 CET] <teratorn> well, possibly different timescale [21:12:53 CET] <JEEB> BtbN: yea that was what I wondered :P what use cases do you have for it since you still have to reorder them to utilize them for pretty much anything [21:13:01 CET] <JEEB> transcoding, presentation... [21:13:06 CET] <JEEB> the latency just moves elsewhere [21:13:10 CET] <rajkosto> the API i want to plugin ffmpeg to gives me ptr to bitstream for one frame, and gpu buffer to fill with that decoded frame [21:13:41 CET] <JEEB> right, so it doesn't have separate push/pull [21:13:58 CET] <JEEB> does it kill that pointer you got after you call its API the next time? [21:14:09 CET] <rajkosto> sometimes if i return error it knows that hte gpu buffer isnt used [21:14:14 CET] <rajkosto> and will submit it next time [21:14:23 CET] <rajkosto> sometimes it doesnt check error and just assumes all have frames :| [21:14:41 CET] <JEEB> just wonder if your layer keeps the pointer [21:14:43 CET] <BtbN> What the hell kinda API is that? [21:14:58 CET] <rajkosto> BtbN, one that works perfectly for the hardware decoder that was avaialble when it was made on one platform [21:16:47 CET] <JEEB> rajkosto: so basically if you keep a pointer to the buffer will be invalidate it after you call its thing again? [21:16:51 CET] <JEEB> that's the main thing [21:17:03 CET] <JEEB> so if you can have the buffers around in your own buffer [21:17:05 CET] <JEEB> -34 [21:17:08 CET] <rajkosto> yes i cant keep a pointer to the buffer [21:17:14 CET] <rajkosto> the gpu one [21:17:20 CET] <JEEB> oh well [21:17:21 CET] <rajkosto> its either fill it now or give it back [21:17:41 CET] <JEEB> anyways, a shitty API and my condolences [21:17:46 CET] <rajkosto> and users of the api that set the "give frames immediately" bool, dont even check the "give it back" sitaution [21:18:09 CET] <rajkosto> they giv enough bitstream to decode a frame, and expect a frame [21:19:02 CET] <JEEB> yea, the problem is that you need to do buffering elsewhere if there's reordering needed [21:19:15 CET] <rajkosto> it parses the timestamp returned, and reorders itself [21:19:16 CET] <JEEB> they've seemingly taken that to themselves or just don't support reordering [21:19:28 CET] <JEEB> which then fights with 99% of all multimedia frameworks :D [21:19:53 CET] <JEEB> I think there was like one or so which libavcodec integrates to which doesn't do reordering itself [21:21:25 CET] <rajkosto> the thing is, there isnt a usable h264 high decoder other than ffmpeg [21:21:42 CET] <rajkosto> other than the APIs exposed by various OSs, but those buffer way more [21:22:22 CET] <JEEB> then your only way forward is to either rework the API you're dealing with, or add the no reorder mode to h264dec [21:23:52 CET] <rajkosto> the tangled web of C that h264dec is wont let me do the latter [21:24:49 CET] <JEEB> then you have the options of either fixing the API you're dealing with or requesting for the feature in h264dec [21:35:07 CET] <neverminder> So if I can't record video and audio simultaneously into one file, is it possible to output video and audio into separate files? [21:36:23 CET] <rajkosto> but you can ! [21:37:44 CET] <marco_> Hallo, i'm very new to ffmpeg, i need to join some clips with different formats, bitrate and other. tryed to convert with command like this ffmpeg -i 28.avi -b 1200k -minrate 1200k -maxrate 1200k -bufsize 1200k -ab 64k -vcodec libx264 -acodec aac -strict -2 -ac 2 -ar 44100 -s 640x360 -y 28_test.mp4 but i've got some error and the output freeze! [21:38:20 CET] <JEEB> first of all with any recent (early 2016 or later) version of FFmpeg the AAC decoder no longer needs the experimental flag [21:38:27 CET] <JEEB> (-strict experimental, which is "-2") [21:38:50 CET] <JEEB> also don't set minrate unless you explicitly need it since it's not a thing in libx264 [21:39:14 CET] <JEEB> also not sure what is joining clips in that one? [21:39:31 CET] <JEEB> if you are joining clips I would have thought of the concat filter [21:39:44 CET] <marco_> sorry i'm new to video editing too.. [21:40:14 CET] <marco_> so i found some example and try it.. [21:40:53 CET] <JEEB> https://trac.ffmpeg.org/wiki/Concatenate#filter [21:41:18 CET] <JEEB> this lets you work with multiple files and you can even then normalize their resolutions etc [21:41:22 CET] <JEEB> -45 [21:42:51 CET] <neverminder> rajkosto: no I can't, wasted countless hours on it already and nothing [21:43:17 CET] <marco_> i have read that page, and made some test, but i don't know wich parameters are mandatory to be normalized.. [21:43:41 CET] <JEEB> neverminder: well anything you have posted has not shown any issues and I do not utilize those modules myself so I have no idea if there are any issues with them if there are any :P [21:43:59 CET] <JEEB> but in theory what you're doing "having multiple inputs" is quite possible as long as you have them on the same time line [21:44:59 CET] <neverminder> JEEB - thing is, I can record audio and video separately jus fine, so surely it's not the modules? [21:45:10 CET] <JEEB> or then ffmpeg.c [21:45:18 CET] <JEEB> I can't say anything without knowing more about the specific issue [21:45:44 CET] <JEEB> but we've already seen multiple people here today doing separate video and audio inputs into a single output so that in general is not the problem [21:48:27 CET] <neverminder> so this is a bug then that only affects me? [21:49:05 CET] <JEEB> not necessarily, but you're the one who's come to this point [21:49:28 CET] <JEEB> I mean, there's plenty of input modules and plenty of cases of where things can possibly fail [21:49:39 CET] <JEEB> the problem is that the outputs you posted that I checked quickly didn't seem to have any signs of errors [21:50:45 CET] <neverminder> no errors indeed, but there's an enormous loop at the end saying "cur_dts is invalid (this is harmless if it occurs once at the start per stream)" [21:51:00 CET] <JEEB> check debug_ts output [21:51:10 CET] <JEEB> that gives you the exact timestamps that ffmpeg.c is dealing with [21:51:42 CET] <JEEB> what it gets out of the "demux", how it looks after ffmpeg.c has mangled the timestamps and how it looks like when things are fed/gotten to/from a decoder [21:51:45 CET] <JEEB> and encoder [21:51:46 CET] <JEEB> and muxer [21:55:42 CET] <marco_> JEEB: Using mediainfo i've found this difference between 2 clips: [21:55:42 CET] <marco_> Overall bit rate:1 344 Kbps - 1 801 Kbps [21:55:42 CET] <marco_> Bit rate : 1 141 Kbps - 1 664 Kbps [21:55:42 CET] <marco_> Width: 528 pixels - 520 pixels [21:55:42 CET] <marco_> Height: 400 pixels - 390 pixels [21:55:44 CET] <marco_> Frame rate:25.000 fps - 29.917 fps [21:55:46 CET] <marco_> Bits/(Pixel*Frame): 216 - 274 [21:55:48 CET] <marco_> Writing library:XviD 1.1.2 (UTC 2006-11-01) - Lavc51.46.0 [21:55:50 CET] <marco_> is possible to join? [21:56:26 CET] <JEEB> just make the resolution the same [21:56:32 CET] <JEEB> VFR should be possible in mp4 [22:01:38 CET] <marco_> what do you mean with resolution whdth and heigth? [22:01:46 CET] <JEEB> yes [22:01:50 CET] <JEEB> use the scale filter [22:02:10 CET] <JEEB> either upscale the smaller one a bit or downscale the larger one [22:02:21 CET] <JEEB> or if there's black borders, crop to match them up [22:04:11 CET] <marco_> Thanks i will make some try. may be in some days i will be here again :-) [22:09:19 CET] <neverminder> JEEB - so is it possible to output audio and video into separate files? Maybe that way I could circumvent this dead end? [22:11:23 CET] <neverminder> I mean I literally just need to record video and audio tracks in sync, doesn't matter how. [22:12:41 CET] <JEEB> you can but I'm not sure how to keep the sync since I have no idea how those two inputs give you timestamps to begin with? [22:12:55 CET] <JEEB> can you not check with -v verbose -debug_ts what on earth is going on there? [22:13:31 CET] <neverminder> I do and I did multiple times - enabling -report flag is the same as -v verbose [22:13:49 CET] <neverminder> what do you mean by timestamps? [22:13:51 CET] <JEEB> but not debug_ts [22:13:54 CET] <JEEB> as far as I remember [22:14:00 CET] <neverminder> yes, debug_ts as well [22:14:02 CET] <JEEB> ok [22:14:12 CET] <neverminder> https://pastebin.com/bV1ePJ2u [22:14:14 CET] <JEEB> thank you [22:14:24 CET] <neverminder> this is a dump with absolutely everything enabled that you mentioned [22:14:54 CET] <JEEB> ok, so it just keeps rolling around like that using CPU or so? [22:15:02 CET] <JEEB> with just outputting the cur_dts thing? [22:15:15 CET] <neverminder> yep, pretty much [22:15:21 CET] <JEEB> now that's funky [22:15:40 CET] <neverminder> doesn't really use much CPU though, not significantly [22:15:48 CET] <JEEB> oh [22:15:51 CET] <JEEB> one thing I noticed [22:16:01 CET] <JEEB> you're not going to get mpeg-1 video encoded with 3840x2160 I think? [22:16:17 CET] <JEEB> libx264 or so recommended, preset superfast or so [22:16:31 CET] <neverminder> what does that mean? how can I enable that? [22:17:01 CET] <JEEB> -c:v libx264 -preset superfast [22:17:14 CET] <JEEB> "give me libx264" "set the preset option to 'superfast'" [22:17:24 CET] <JEEB> :v means "for the video" [22:17:31 CET] <neverminder> can I just put it anywhere in the command string? [22:17:38 CET] <JEEB> after the input, basically [22:17:48 CET] <JEEB> that's the main difference in ffmpeg.c [22:18:03 CET] <JEEB> if options go before -i [input], those are for reading/decoding [22:18:11 CET] <JEEB> if they go after, those are for encoding/writing [22:19:22 CET] <neverminder> so I just tried this: ffmpeg -y -report -debug_ts -f v4l2 -input_format mjpeg -s uhd2160 -i /dev/video0 -f pulse -channels 1 -i default -c:v libx264 -preset superfast video.mpg [22:19:24 CET] <neverminder> no change [22:19:48 CET] <JEEB> oh, mpg. try mkv [22:20:07 CET] <JEEB> also post log [22:20:17 CET] <JEEB> although I have a feeling that the v4l2 thing isn't read from for some reason? [22:20:28 CET] <JEEB> wait [22:20:38 CET] <JEEB> why are there no demuxer/demuxer+ffmpeg lines... [22:20:42 CET] <JEEB> only encoder/muxer [22:20:46 CET] Action: JEEB scratches his head [22:21:12 CET] <neverminder> tried with mkv, no change: https://pastebin.com/8i3LMdgc [22:21:42 CET] <neverminder> is there something weird going on? [22:22:01 CET] <JEEB> weird as heck [22:22:13 CET] <JEEB> those debug_ts lines are not supposed to just stop [22:22:27 CET] <JEEB> can you please make a ticket about this with that output on trac? [22:22:36 CET] <JEEB> it's as if one of the inputs is blocking the other one [22:22:42 CET] <JEEB> because nothing's getting read [22:22:43 CET] <neverminder> I run it, wait a little and kill it with Ctrl-C if that changes anything? [22:23:17 CET] <neverminder> you mean a bug report with this output included? [22:23:21 CET] <JEEB> yes [22:23:33 CET] <neverminder> how should I describe the bug? [22:23:39 CET] <JEEB> although I would test with the latest git HEAD as well [22:23:56 CET] <JEEB> in case the issue is fixed there [22:24:25 CET] <JEEB> you only need libx264, pulse, v4l2 and whatever ffmpeg.c picked for mkv [22:24:28 CET] <JEEB> (for audio) [22:24:35 CET] <JEEB> you don't need to install it, just build it [22:24:57 CET] <JEEB> neverminder: a good enough description would be "ffmpeg.c stalls after N frames when capturing v4l2 video and pulse audio" [22:25:04 CET] <JEEB> because that's how it seems like [22:25:17 CET] <JEEB> the debug_ts stuff stops so there's some sort of stall [22:25:41 CET] <JEEB> neverminder: if you look at the beginning there's some "demuxer -> " and "demuxer+ffmpeg ->" lines [22:25:47 CET] <JEEB> but then they disappear [22:25:49 CET] <neverminder> yeah I see that [22:25:52 CET] <JEEB> which means that ffmpeg.c isn't getting things read [22:25:55 CET] <JEEB> for some reason [22:27:23 CET] <neverminder> ok thanks, I'll try all the stuff you recommended and get back as soon as I have something [22:50:39 CET] <JEEB> neverminder: yea I guessed that's the initial response you'll get :D "test with current git HEAD" [23:12:57 CET] <rajkosto> JEEB, after attempting a decode, is there something that will tell me the strema has no b-frames [23:13:40 CET] <JEEB> yes, you can see that (among other things) in the init() function [23:13:48 CET] <JEEB> also I think it gets updated during decoding from sps parsing [23:15:40 CET] <rajkosto> it does, but i cant access those private codec vals from api using code [23:17:23 CET] <JEEB> at this point it sounds better to just check what updates that value and look at adding support for that flag that's in mpeg-2 or mpeg-4 part 2 :P [23:17:51 CET] <rajkosto> no ill just check if it has b-frames and only if it doesnt insert null frames [23:17:55 CET] <rajkosto> packets* [23:19:07 CET] <BtbN> I'm pretty sure randomly sending NULL frames is not supported and can lead to undefined behaviour, including crashes [23:20:02 CET] <rajkosto> i mean packets, to the decoder, to force a flush and get a frame out [23:22:10 CET] <BtbN> yes [23:22:11 CET] <BtbN> https://trac.ffmpeg.org/ticket/6775#comment:14 [23:22:14 CET] <BtbN> it's not supported [23:22:59 CET] <BtbN> The only time NULL packets are allowed and expected is after EOF to drain the decoder [23:23:20 CET] <rajkosto> then how do i get frames out that i know are fully decoded but ffmpeg is just keeping from me [23:23:21 CET] <BtbN> at any other time, the behaviour is undefined [23:23:59 CET] <BtbN> I'd guess set any low-latency stuff you can find, and turn off threading, as multi-threaded decoding mandates some buffer [23:24:16 CET] <rajkosto> i think i did [23:33:19 CET] <rajkosto> JEEB, using the new api, giving it the null avpacket doesnt work anymore, it only works for the first frame :P [23:33:38 CET] <JEEB> yea, because it's properly resetting the decoder :P [23:33:45 CET] <BtbN> With the old API it also doesn't work anymore, since it was made a wrapper around the new one [23:33:50 CET] <JEEB> yea [23:33:54 CET] <rajkosto> im on some old 3.2 from march [23:34:02 CET] <rajkosto> BtbN, so what, im supposed to just find another decoder to use ? [23:34:10 CET] <JEEB> or you request/add the feature you need [23:34:11 CET] <JEEB> yes [23:34:33 CET] <JEEB> because you're abusing the API in ways it's not meant to be done so if it breaks unfortunately you get to keep both pieces [23:34:50 CET] <JEEB> if you really want the "no reordering" mode you will have to request it or make it yourself [23:35:08 CET] <BtbN> To me this sounds like you want to be a hwaccel inside of lavc. [23:35:35 CET] <rajkosto> huh [23:35:52 CET] <BtbN> Those site inside of the decoder, and get the raw data [23:36:23 CET] <rajkosto> i have no clue, nor is there any documentation on how to use hwaccel modes in ffmpeg btw [23:36:45 CET] <BtbN> An API that wants decoded frames, but not re-ordered, just makes no sense to me. Why does it want that? And why would a few frames delay hurt it so much? [23:37:20 CET] <rajkosto> it just leads to hangs after the video is done for my api user, or hang immediately after first frame isnt output [23:37:45 CET] <BtbN> If this is some weird real-time remote-gaming/desktop thing, you want to use I/P-only anyway, and don't have the problem. [23:37:55 CET] <rajkosto> nope, decoding video from file [23:38:09 CET] <rajkosto> it just expects to get a frame back if it gives it enough nals to decode af rame [23:38:23 CET] <BtbN> "it"? [23:38:27 CET] <rajkosto> the api user [23:38:41 CET] <BtbN> That's not how video decoders work and that api is misdesigned then. [23:38:57 CET] <rajkosto> not mine to change it, it worked fine when it was implemented using the platform's hardware decoder [23:39:32 CET] <BtbN> Every higher level hardware decoder I ever worked with also does the re-ordering for you [23:39:44 CET] <BtbN> I feel like your issue is somewhere else, some misunderstanding somewhere. [23:40:06 CET] <rajkosto> api user sets "single frame decoding mode" to true, api user gives enough nals for a frame, api user doesnt get a frame back, api user hangs [23:40:39 CET] <BtbN> And what are you supposed to do if you don't have the required references yet? That makes no sense. [23:41:00 CET] <rajkosto> even when single frame decoding mode isnt true, the first few gpu buffers i return false for, it ends up not giving me enough to finish the video at the end, and since it does a timestamp comparison on the end frame, it hangs at the end [23:42:03 CET] <rajkosto> well it clearly has the required references for that first use case i explained, since when using the old decode2 api and feeding it null packets after each packet, it works. [23:55:58 CET] <rajkosto> actually, the first frame im giving it is a keyframe, it cannot depend on any frames, so ffmpeg SHOULD give me it back right away [23:56:24 CET] <rajkosto> is there a guide on how to disable all the threading and acceleration to get lowest latency ? i might not have done all i can [23:57:11 CET] <JEEB> threads=1 should be enough (or slice-based threading) [23:57:18 CET] <JEEB> decoding really isn't too hard [23:57:30 CET] <rajkosto> ffmpeg.ctx->thread_count = 1; [23:57:44 CET] <JEEB> otherwise the reordering delay might just be globally utilized [23:57:51 CET] <JEEB> so it doesn't care about the picture type [23:57:56 CET] <rajkosto> it might just delay by max_b_frames in the SPS always [23:58:01 CET] <JEEB> yes [23:58:06 CET] <rajkosto> whereas what i need is frames as soon as possible [23:59:21 CET] <JEEB> might want to try with a constrained baseline sample with the SPS value being at "no reordering needed" [23:59:27 CET] <JEEB> and check the decoding with that [23:59:50 CET] <JEEB> should be relatively simple to generate with -c:v libx264 -profile baseline -t 15 or so [23:59:53 CET] <JEEB> with the cli [00:00:00 CET] --- Mon Dec 4 2017

1 0

ffmpeg-devel.log.20171202
by burek 03 Dec '17

03 Dec '17

[00:50:41 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:52bb493afaa5: avcodec/jpeglsdec: Check ilv for being a supported value [00:50:42 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:93854b705273: avcodec/jpeglsdec: Check for end of bitstream in ls_decode_line() [00:50:43 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:56cc35019e4a: avcodec/aacdec_fixed: Fix integer overflow in predict() [00:50:44 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:52ebd1a0dc2f: avcodec/aacdec_fixed: Fix integer overflow in apply_dependent_coupling_fixed() [00:50:45 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:a3bb922c4da1: avcodec/xan: Improve overlapping check [00:50:46 CET] <cone-963> ffmpeg 03Luca Barbato 07release/3.0:66754f0a962e: avformat: Free the internal codec context at the end [00:50:47 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:4d9321136d7f: avcodec/xan: Check for bitstream end in xan_huffman_decode() [00:50:48 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:122634a580df: avcodec/h264idct_template: Fix integer overflows in ff_h264_idct8_add() [00:50:49 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:21ae8b4869e2: avcodec/aacsbr_fixed: Fix division by zero in sbr_gain_calc() [00:50:50 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:4fbee4272793: avutil/softfloat: Add FLOAT_MIN [00:50:51 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:b45971a95557: avcodec/sbrdsp_fixed: Fix integer overflow in shift in sbr_hf_g_filt_c() [00:50:52 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:b9e9c5cee03f: avcodec/cngdec: Fix integer clipping [00:50:53 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:f33f13172cfe: avcodec/snowdec: Fix integer overflow in header parsing [00:50:54 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:f2763b8ba80c: avcodec/mdct_*: Fix integer overflow in addition in RESCALE() [00:50:55 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:43299eabeabc: avcodec/aacdec_fixed: Fix undefined shift [00:50:56 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:91aadc6a5b8e: avcodec/aacpsdsp_template: Fix integer overflows in ps_decorrelate_c() [00:50:57 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:b8a6b5602762: avcodec/x86/mpegvideodsp: Fix signedness bug in need_emu [00:50:58 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:2fc1a8ba4984: avcodec/h264dec: Fix potential array overread [00:50:59 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:4171249d7632: avcodec/vc2enc: Clear coef_buf on allocation [00:51:00 CET] <cone-963> ffmpeg 03Fredrik Hubinette 07release/3.0:74677deaca81: avformat/mov: Check size of STSC allocation [00:51:01 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:b8a10f10cc5f: avcodec/snowdec: Check intra block dc differences. [00:51:02 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:12aea29a9596: avcodec/snowdec: Check for remaining bitstream in decode_blocks() [00:51:03 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:d1421edab7c1: avcodec/wmv2dec: Check end of bitstream in parse_mb_skip() and ff_wmv2_decode_mb() [00:51:04 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:bc65abecd31f: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_DD137iL0() [00:51:05 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:b9b4d34ecfdd: avcodec/zmbv: Check that the buffer is large enough for mvec [00:51:06 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:a3606385f075: avcodec/mlpdsp: Fix undefined shift ff_mlp_pack_output() [00:51:07 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:bf44f250a223: avcodec/hevcdsp_template: Fix invalid shift in put_hevc_epel_bi_w_v() [00:51:08 CET] <cone-963> ffmpeg 03Jacob Trimble 07release/3.0:20e78d53394f: avformat/mov: Propagate errors in mov_switch_root. [00:51:09 CET] <cone-963> ffmpeg 03Dale Curtis 07release/3.0:712814fb17b6: Use ff_thread_once for fixed, float table init. [00:51:10 CET] <cone-963> ffmpeg 03Dale Curtis 07release/3.0:c09d587ac54d: Fix undefined shift on assumed 8-bit input. [00:51:11 CET] <cone-963> ffmpeg 03Dale Curtis 07release/3.0:50b22648100e: Close ogg stream upon error when using AV_EF_EXPLODE. [00:51:12 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:abff307736fb: avcodec/mpeg4videodec: Check also for negative versions in the validity check [00:51:13 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:2214afdf408c: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_FIDELITYi* [00:51:14 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:71e40180cb1d: avcodec/kgv1dec: Check that there is enough input for maximum RLE compression [00:51:15 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:78b6e8fb233f: avcodec/mlpdsp: Fix signed integer overflow, 2nd try [00:51:16 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:a65633aa9d22: avcodec/hevcdsp_template: Fix undefined shift in put_hevc_epel_bi_w_h() [00:51:17 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:44dc83f0e07a: avcodec/j2kenc: Fix out of array access in encode_cblk() [00:51:18 CET] <cone-963> ffmpeg 03Dale Curtis 07release/3.0:b01020a0501a: avformat/utils: Prevent undefined shift with wrap_bits > 64. [00:51:19 CET] <cone-963> ffmpeg 03Dale Curtis 07release/3.0:e6c6bb218e0b: avcodec/vorbis: 1 << 31 > int32_t::max(), so use 1u << 31 instead. [00:51:20 CET] <cone-963> ffmpeg 03Dale Curtis 07release/3.0:532f0d1278c0: Don't manipulate duration when it's AV_NOPTS_VALUE. [00:51:21 CET] <cone-963> ffmpeg 03Dale Curtis 07release/3.0:06a6f73ad83b: avcodec/vorbis: Fix another 1 << 31 > int32_t::max() with 1u. [00:51:22 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:2bc6b9b2a9c9: Changelog: update [01:00:17 CET] <atomnuker> durandal_170: you can do the hflipping in-place, you know [01:00:36 CET] <atomnuker> start at the middle and load up 2 regs at once, shuf them and swap them [01:02:30 CET] <atomnuker> that ought to speed it up even more [01:25:01 CET] <ElementalOrange> How are asm/SIMD optimizations normally written? Are they just written by hand with an intimate understanding of ASM and x86? [01:25:22 CET] <JEEB> how intimate your knowledge is depends, but yes [01:25:27 CET] <atomnuker> yep [01:25:39 CET] <JEEB> the basic idea is that you define some function pointers and then implement the function in SIMD [01:26:03 CET] <ElementalOrange> How does one learn SIMD or how to write decent ASM for it? [01:27:03 CET] <JEEB> that's a good question since you generally when starting don't really know what's good for what. that said, nobody stops you from making something really basic and then getting reviews on how to improve things [01:27:21 CET] <JEEB> also intel publishes the instruction set books as PDF as one darn large listing for searching [01:27:30 CET] <JEEB> (for x86/x86_64) [01:27:48 CET] <JEEB> then there's NEON for ARMv7+ [01:28:01 CET] <atomnuker> ElementalOrange: just start from one of the existing functions and play around with it to do what you'd like it to do [01:28:02 CET] <wm4> just don't write them as intrinsics [01:28:09 CET] <wm4> they have little to none chance of being accepted in ffmpeg [01:28:17 CET] <Shiz> intrinsics are bad [01:29:44 CET] <ElementalOrange> Feels very daughting lol [01:29:55 CET] <jdarnley> There is a half-decent introduction on the VideoLAN wiki that I transcribed and BBB has done a better blog post on the subject. [01:30:09 CET] <jdarnley> https://wiki.videolan.org/X264_asm_intro/ [01:30:13 CET] <JEEB> https://blogs.gnome.org/rbultje/2017/07/14/writing-x86-simd-using-x86inc-as… [01:30:21 CET] <jdarnley> https://blogs.gnome.org/rbultje/2017/07/14/writing-x86-simd-using-x86inc-as… [01:30:27 CET] <jdarnley> snap [01:31:23 CET] <ElementalOrange> What is normally used as function performance analysis? [01:31:26 CET] <JEEB> ok, the blog is already better than the old wiki because it has "this is what we're trying to do, and here's a SIMD example of defining the same thing" [01:31:31 CET] <ElementalOrange> s/as/for [01:31:46 CET] <jdarnley> FFmpeg's timer.h header, perf, checkasm [01:31:52 CET] <JEEB> ^ [01:32:02 CET] <JEEB> if you look at SIMD patches you will see the functions compared [01:33:04 CET] <ElementalOrange> Are all these questions answered somewhere on an FFmpeg FAQ? [01:33:28 CET] <jdarnley> maybe the benchmarking question is [01:33:44 CET] <JEEB> for the actual writing BBB's blog post that we linked seems darn good [01:33:57 CET] <ElementalOrange> How about what a "two-loops algorithm" in ASM is [01:33:58 CET] <atomnuker> ElementalOrange: we usually use libavutil/timer.h:START_TIMER() and STOP_TIMER() [01:34:10 CET] <JEEB> yea that was the thing :) [01:34:13 CET] Action: jdarnley has yet to read it to the end [01:35:20 CET] Action: JEEB hopes someone who knows NEON will notice https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221518.html [01:35:32 CET] <JEEB> FFmpeg stopped building with ARM clang pretty suddenly :/ [01:38:51 CET] <jdarnley> ElementalOrange: what do you mean by "two-loops algorithm"? [01:39:24 CET] <jdarnley> I'm sure there are meny examples of nested loops in assembly [01:39:53 CET] <ElementalOrange> specifically to compute the integral image [01:39:56 CET] <jamrial> JEEB: also gcc aarch64 it seems [01:40:19 CET] <jdarnley> What is an integral image? [01:40:54 CET] <jdarnley> Isthis some specific Computer Science term I am not familiar with? [01:40:56 CET] <ElementalOrange> https://en.wikipedia.org/wiki/Summed-area_table [01:41:36 CET] <jdarnley> If we have one of those somewhere then feel free to write assembly for it. [01:42:07 CET] <ElementalOrange> jdarnley: It's used in NLM [01:43:04 CET] <cone-963> ffmpeg 03Michael Niedermayer 07n3.0.10:HEAD: avcodec/jpeg2000: Only allocate Jpeg2000Pass for the encoder [01:47:37 CET] <ElementalOrange> Any ideas what could cause a filter to not be using 100% CPU? I see about 50% usage across 4/8 cores/threads [02:37:49 CET] <jamrial> wm4: "../video/decode/vd_lavc.c:291:13: error: unknown type name AVCodecHWConfig" [02:38:52 CET] <wm4> jamrial: wut [02:39:31 CET] <jamrial> travis for mpv is failing with that and similar errors [02:40:02 CET] <wm4> oh yeah, I noticed that [02:40:03 CET] <jamrial> you probably missed adding a header in your recent vd_lavc refactoring [02:40:07 CET] <jamrial> ah ok [02:40:22 CET] <wm4> it should get getting the correct ffmpeg version though, and mpv's configure also requires an appropriate libavcodec pkg-config version [02:40:26 CET] <wm4> so no idea what travis wants [02:40:46 CET] <jamrial> it's using libav, though [02:40:46 CET] <wm4> I mean it does include avcodec.h [02:40:51 CET] <wm4> huh [02:40:54 CET] <wm4> oh damn [02:41:03 CET] <wm4> right, I think that was not merged into libav yet [02:41:05 CET] <wm4> oops [02:45:25 CET] <jamrial> that explains why appveyor didn't also fail, haha [03:08:10 CET] <ElementalOrange> Was --enable-gprof replaced by something [03:08:43 CET] <ElementalOrange> Oh, Oprofile [04:23:28 CET] <Compn> jkqxz : re amd header , i know that you are against including it, but would you consider it a blocker or veto it? [04:23:39 CET] Action: Compn still reading long thread [04:24:24 CET] <Compn> er maybe i missed the other thread [04:27:54 CET] <atomnuker> _make_a_separate_repo_ [04:28:00 CET] <atomnuker> how hard can it be? [04:28:35 CET] <Compn> its not hard [04:28:40 CET] <Compn> its already on github [04:29:18 CET] <Compn> oh its a git submodule [04:29:26 CET] <Compn> atomnuker : would a git submodule be acceptable ? [04:29:37 CET] <Compn> seperate repo but git auto pulls it in ? [04:30:12 CET] <atomnuker> yeah, sure [04:30:14 CET] <Compn> oh git wont pull new submodules down automatically [04:30:24 CET] <atomnuker> nah, you have to git submodule init [04:30:29 CET] <Compn> As you know, "git pull" won't update the submodules, and "git submodules update" won't download the latest HEAD of those submodules either. [04:30:30 CET] <Compn> To update all of your submodules to their latest upstream revision, you can use [04:30:30 CET] <Compn> git submodule foreach git pull [04:30:38 CET] Action: Compn stabs self in head [04:30:42 CET] <atomnuker> but its fine imo as long as its added in the docs somewhere or maybe during the configure scipt [04:31:24 CET] <atomnuker> "unable to find hwaccel headers, do a git submodule init to pull them and enable amf/cuda/qsv" [04:31:30 CET] <Compn> ideally, where should this header go? hmm [04:31:34 CET] <Compn> in xorg ? [04:31:49 CET] <atomnuker> headers? [04:32:01 CET] <atomnuker> go as in where? [04:32:09 CET] <Compn> i mean, which project should ferry it into a users system [04:32:17 CET] <Compn> or would it be distro responsibility ? [04:32:35 CET] <Compn> i mean, shouldnt this amf encoder header come with the binary driver ? [04:32:36 CET] <atomnuker> this is for build-time use only afaik [04:32:51 CET] <SortaCore> you guys aren't fragmenting things I hope o.o [04:33:22 CET] <Compn> SortaCore : amd wants ffmpeg to include a header from its sdk in our codebase [04:33:48 CET] <atomnuker> so who has access to the videolan git repo to add another one for the headers? j-b? [04:34:08 CET] <Compn> sure [04:34:12 CET] <Compn> j-b or thresh [04:34:15 CET] <SortaCore> ok, so why do you sound like you're making loads of different repo variants? [04:34:44 CET] <Compn> SortaCore : i'm asking who and where it should be located, if not in our repo... [04:35:16 CET] <SortaCore> dunno about y'all but git has always been a painful thing to work with [04:35:34 CET] <Compn> k [04:35:41 CET] <atomnuker> something like https://git.videolan.org/?p=ffhw_headers.git;a=log;h=HEAD maybe [04:35:52 CET] <SortaCore> why could you not add it like say, the intel stuff? [04:36:11 CET] <Compn> SortaCore : theres a large thread on ffmpeg-devel if you wish to read it :) [04:36:28 CET] <Compn> i'm trying to find a consensus on the next step... [04:36:39 CET] <SortaCore> it's 3am tho [04:36:50 CET] <SortaCore> I am like 2 mins from sleeps [04:36:55 CET] <Compn> good night SortaCore :) [04:36:58 CET] <SortaCore> is it just license dubiousness? [04:37:20 CET] <Compn> read the thread sometime when its not so late :) [04:37:35 CET] <Compn> and no, its now MIT license [04:37:36 CET] <atomnuker> okay, whatever, what's left is to agree on a name [04:38:07 CET] <Compn> atomnuker : so we are going to move nv headers there too then? [04:38:15 CET] <SortaCore> yes, should it be amd, AMD or aMD camelCase [04:38:27 CET] <atomnuker> jkqxz, BtbN: does ffhw_headers sound fine for a repo name? [04:38:40 CET] <Compn> SortaCore : he means the repo name, not amd name heh [04:38:41 CET] <atomnuker> Compn: yes, lets move everything external we have [04:38:50 CET] <Compn> atomnuker : ok, good idea :) [04:39:00 CET] <SortaCore> yea, I was just being sarcastic, y'all keep up the good work [04:39:12 CET] <Compn> j-b : what do you guys do with your external headers? :) [04:39:37 CET] <SortaCore> one question tho, when transcoding should it be the same hw_device_ctx in decoder + encoder? [04:39:46 CET] <SortaCore> or do you initialise two dev ctxs? [04:40:07 CET] <Compn> atomnuker : i'd say ffheaders , keep it simpler [04:41:41 CET] <atomnuker> yeah, okay, that's another valid name [04:42:46 CET] <SortaCore> (does no one know?) [04:43:01 CET] <Compn> (i am unable to answer your question) [04:43:17 CET] <SortaCore> (thanks for acknowledgement) [04:43:19 CET] <philipl> SortaCore: it's the same device. [04:43:32 CET] <SortaCore> danke vaas [04:43:58 CET] <SortaCore> this isn't really demoed in any of the examples [04:44:06 CET] <SortaCore> they do either decode or encode, not both [04:44:33 CET] <philipl> No one got round to writing a transcode example, but that's how the ffmpeg tools works. Obviously much more complicated [04:45:40 CET] <philipl> Compn: for what it's worth, I'd have been happy to keep the headers in tree but I actually think a submodule works quite well. The fact that it doesn't automatically follow a branch means we can explicitly set the submodule hash to point to the version of the headers we want at a particular point in time. [04:45:52 CET] <SortaCore> yea, ffmpeg seems to come with quite a steep learning curve once you pass out of examples/googleables [04:45:57 CET] <philipl> and the fact that submodules don't checkout automatically can make people happy who don't want the headers automatically... [04:46:08 CET] <philipl> The things that make submodules horrible to use work in our favour here, arguably :-) [04:47:22 CET] <SortaCore> why do you want to keep the header out of the full build? [04:48:15 CET] <philipl> I don't want to keep it out, but I think I don't represent the emerging concensus. [04:48:36 CET] <SortaCore> ultimately it's about user ease of use, right [04:48:54 CET] <philipl> That's my priority [04:49:17 CET] <SortaCore> so my brain's instantly going to big headers, interference with ffmpeg stuff, formats C:\ when intel qsv is in same repo [04:49:26 CET] <SortaCore> these would be valid concerns [04:50:00 CET] <SortaCore> if it's just a longer make should be ok [04:50:14 CET] <Compn> philipl : yes i'm in agreement with you, that including headers is better for users... [04:52:16 CET] <atomnuker> moderation is the key however lest the repo will become a dumpster for "vendor's first hwdec api" [04:52:51 CET] <atomnuker> and no, submodules are alright, you just educate users by messages [04:53:21 CET] <atomnuker> its not the first thing users would learn to know when compiling ffmpeg, its just going to be one of many [04:53:40 CET] <atomnuker> like "hwaccels are enabled by default, but you still need the distro's dev packages" [04:58:10 CET] <wm4> just don't set the dumpster on fire [04:58:14 CET] <wm4> then we don't have to care [05:07:15 CET] <philipl> wm4: I thought this dumpster was always on fire [05:08:29 CET] <wm4> probably is [05:18:54 CET] <Compn> surprised nvidia hasnt fixed their nonsense sdk [05:19:01 CET] <Compn> so people can download it [05:19:31 CET] <philipl> I don't know how they expected people to use it. [05:20:21 CET] <philipl> Even the sdk that you do download is organised like garbage. It doesn't make it clear which headers are actually for development and which are part of the samples [05:21:51 CET] <atomnuker> spoiler warning: they care exactly 0% about general users [05:21:57 CET] <atomnuker> absolutely 0% [05:22:22 CET] <atomnuker> they care about other companies using the sdk to create producs and support for their hardware in their products [05:27:26 CET] <philipl> Too true. [05:27:45 CET] <philipl> They care about us using it (see their ffmpeg stuff on the website) but not enough to make it consumable. [05:30:52 CET] <wm4> lol [10:34:21 CET] <BtbN> atomnuker, I still think one big repo with all the headers is a horrible idea. It defeats the entire point of not including external headers. [10:34:40 CET] <BtbN> And with avisynth, it's not even hw [10:49:50 CET] <durandal_170> atomnuker: i get quite good performance, and your approach would complicate things even more [10:58:43 CET] <atomnuker> not really [10:59:22 CET] <atomnuker> BtbN: fine then, lets have one for each separate header [11:00:10 CET] <atomnuker> pick a name for the nvidia one and pm thresh to make one, someone with github access can mirror it later [11:00:18 CET] <BtbN> I don't think we even need one for each header. AMD seems to be maintaining their repository well. [11:00:43 CET] <atomnuker> alright, then just for the ones we have right now [11:01:23 CET] <BtbN> And there were people arguing about not really needing it for avisynth anymore as well? But I don't follow that stuff close enough to tell. [11:02:55 CET] <BtbN> I'm gonna go with ffmpeg-nv-codec-headers. Any objections? [11:03:03 CET] <atomnuker> I'm pretty absolutely sure no one uses it anymore, I'l lsend a patch to remove it tonight [11:03:29 CET] <nevcairiel> i'm pretty sure people still use avisynth =p [11:03:39 CET] <atomnuker> well, I meant that interface [11:03:46 CET] <atomnuker> with those headers [11:03:52 CET] <atomnuker> what are the headers for anyway? [11:04:01 CET] <nevcairiel> to build avisynth support in ffmpeg? [11:04:02 CET] <nevcairiel> :) [11:04:21 CET] <atomnuker> so an avisynth filter? [11:04:36 CET] <nevcairiel> i think its a demuxer that can read .avs scripts [11:06:46 CET] <atomnuker> apparently there's been a regression since oct 2016 for msvc builds of avisynth or something [11:07:13 CET] <nevcairiel> doubt many people build msvc outside of using it for development [11:09:28 CET] <BtbN> contacted thresh. It's either going to be ffmpeg-nv-codec-headers or ffmpeg/nv-codec-headers so it shows up under the + sign, like the vlc language bindings and forks [11:47:50 CET] <durandal_170> Compn: why you do not share ideas you get via various conferences you visit with rest of community? [12:32:04 CET] <Compn> durandal_170 : you are assuming i go to any conferences [12:32:25 CET] <Compn> i do not. vdd is the only media conference i've been to. [12:42:12 CET] <jkqxz> Compn: My main problem with including the AMD header is that, as far as I can tell, there are no positive arguments for it while there are definitely arguments against it. [12:44:26 CET] <jkqxz> The only two points in favour that people have made seem to be "Nvidia has it so AMD should do the same thing" and "AMD users are idiots who can't install headers themselves". I don't regard either of those as useful positive arguments. [12:49:57 CET] <jkqxz> If moving the Nvidia headers to a separate repo allows us to get past the first point so that people stop thinking that including the AMD header is somehow not a terrible idea then I am all in favour of it. [13:11:47 CET] <durandal_170> Compn: then other devs, ping them [14:49:19 CET] <JEEB> is there maintenance going on with the trac? [14:49:58 CET] <durandal_170> we do not have admins [14:50:13 CET] <JEEB> I know, it was a rhetorical question [15:03:48 CET] <cone-094> ffmpeg 03Paul B Mahol 07master:bbfcb1b7c891: avfilter/vf_threshold: add x86 SIMD [15:25:26 CET] <iive> is there still problem with trac? seems to work for me. [15:25:53 CET] <JEEB> responds quickly again [18:26:26 CET] <cone-886> ffmpeg 03Martin Vignali 07master:b37196adff75: avutil/x86util : add macro for loading a 128 bits constants in an xmm or in each part of an ymm in order to simplify avx2 asm func [18:26:26 CET] <cone-886> ffmpeg 03Martin Vignali 07master:be6d1f9632e2: avcodec/x86/bswapdsp : use macro for 128 bits constants loading in xmm or ymm [18:49:01 CET] <daddesio> atomnuker: I sent my patchset to the ML. https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221563.html [18:49:26 CET] <daddesio> For some reason patch 2/4 got submitted twice. [18:55:54 CET] <sfan5> anyone familiar with the hevc code who could tell me how to check if a frame is used as a reference by other frames? [19:00:36 CET] <BtbN> look at all the hevc hwaccels [19:00:42 CET] <BtbN> they all grab that information in some way [19:15:33 CET] <cone-886> ffmpeg 03Thomas Köppe 07master:53c492640c6b: avutil/mem: Add DECLARE_ASM_ALIGNED macro for DJGPP architecture. [19:15:34 CET] <cone-886> ffmpeg 03Dale Curtis 07master:09494d098405: avformat/oggdec: Respect AVERROR codes returned by ogg parsers. [19:15:35 CET] <cone-886> ffmpeg 03John Stebbins 07master:00d454ed2ca3: lavf/movenc: add sdtp (sample dependency) box [19:20:36 CET] <kurosu> sfan5, you can't know that in advance - as long it's in the dpb, it could be used anytime, until it is actually removed [19:21:42 CET] <kurosu> if you really want to understand (which I don't), there's in the free specs 8.3.2 "decoding process for reference picture set" [19:23:01 CET] <sfan5> hm that makes sense [19:23:22 CET] <kurosu> so, in short, if you hoped to predict that, maybe you can get it right 80% of the time (eg that's the pattern seen, so that frame should be used) [19:23:41 CET] <kurosu> but you may find streams that don't work that way, and you're toast [19:23:42 CET] <sfan5> what does the nal->ref_idc == 0 in h264_slice.c do then? since it's used for AVDISCARD_NONREF, which I'm looking to implement for hevc [19:23:46 CET] <JEEB> yea, future frames can utilize you until you drop out of the reference picture set [19:24:41 CET] <jkqxz> nal_ref_idc == 0 tells the decoder it will never be referenced by future frames. [19:24:47 CET] <faLUCE> Hello. My library ( https://github.com/paolo-pr/laav ) uses FFMpeg. I chose the GPL 3.0 license and specified it in EACH file of the project. Please can you help me in checking if is it all ok or I have to add something more? [19:24:51 CET] <JEEB> sfan5: the best reference for that is http://www.itu.int/rec/T-REC-H.264-201704-I/en [19:25:10 CET] <JEEB> jkqxz: oh, so there's a flag like that [19:25:11 CET] <jkqxz> The equivalent for H.265 is an "_N" NAL unit type. [19:25:22 CET] <JEEB> is this like the leading pictures? [19:25:26 CET] <sfan5> that sounds like what i wanted to hear [19:25:48 CET] <jkqxz> Note that an encoder need not ever mark any frames like that, but sensible encoders will. [19:26:09 CET] <kurosu> ok, so your question was actually: how hevc indicate a frame is dropped from dpb [19:27:49 CET] <sfan5> so i would need to check for HEVC_NAL_TRAIL_N, HEVC_NAL_TSA_N, ... right? [19:28:40 CET] <sfan5> JEEB, i've downloaded that spec but it's quite opaque if you're looking at codec internals for the first time >.> [19:29:23 CET] <JEEB> true [19:29:24 CET] <jkqxz> kurosu: When it's dropped is harder, you have to track it through the reference picture sets. nal_ref_idc or _N are it never being available for reference at all. [19:29:30 CET] <JEEB> yea [19:29:38 CET] <JEEB> also usually you only know if it's dropped later [19:29:48 CET] <JEEB> while if you want to drop it from decoding altogether you have to know before hand [19:29:52 CET] <JEEB> as in, when you get the packet [19:29:58 CET] <faLUCE> I also ask if is it possible to link the library in the official FFmpeg page [19:30:05 CET] <jkqxz> sfan5: Yes, the _N nal_unit_type values are what you want to look for. [19:30:15 CET] <sfan5> okay thanks [19:30:43 CET] <kurosu> jkqxz, probably, I wouldn't know - it's just that the question was more generic [19:30:45 CET] <JEEB> faLUCE: that would imply some sort of push for your thing which I think is incorrect without people having experience in it and it being something of enough weight that can be recommended without further thoughts [19:31:25 CET] <faLUCE> JEEB: I did not understand what you meant (forgive my poor english) [19:31:51 CET] <faLUCE> do you mean that I need more feedback before pushing it in the official page? [19:32:20 CET] <JEEB> you have to be something generally recommended by a large enough majority to get some sort of official push from the FFmpeg project [19:33:02 CET] <faLUCE> JEEB: I see. what about the license? Is the procedure I followed correct or do I have to add something more? [19:33:32 CET] <faLUCE> (all the source is open and I added the GPL 3.0 and later notice in each file of the project) [19:33:36 CET] <kurosu> sfan5, maybe you can track that through ff_hevc_unref_frame, and check the cases not resulting from an error [19:34:06 CET] <sfan5> that sounds like it'd be too much work just to implement skip_loop_filter [19:34:14 CET] <sfan5> as in not worth the effort [19:35:16 CET] <JEEB> faLUCE: your thing's license can be whatever it is, the stuff is just that you have to follow FFmpeg's license when distributing binaries (which shouldn't be hard for a GPLv3 thing :P) [19:35:21 CET] <kurosu> in that case you could then have some marker saying "not deblocked", and whenever the frame is actually accessed, you do that [19:35:36 CET] <kurosu> but you also have SAO after DBF, so... [19:35:57 CET] <faLUCE> JEEB: I don't have any binary in my library. It is a header only library [19:36:18 CET] <JEEB> faLUCE: also stop having this darn discussion duplicated, move just onto #ffmpeg [19:36:51 CET] <kurosu> sounds cumbersome: when DBF/SAO are performed, you can't know if the frame will be reference or not, and postponing these post filters would require storing all the post filter info... [19:44:08 CET] <kurosu> sfan5, that's for s/w decoding? on what platform? [19:45:09 CET] <sfan5> just continuing what this patch implemented partially http://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176112.html [19:49:19 CET] <kurosu> I'd have transformed that code in report_progress + return, because there's still sao done afterwards [19:52:36 CET] <sfan5> just googled that and it sounds like it should skip that too [19:53:43 CET] <sfan5> guess i'll do exactly what you suggested [19:53:57 CET] <kurosu> that's probably occurring on <10% of the pixels, so that's not a big win anyway [19:54:49 CET] <kurosu> the case where it is partially safe (frame not referenced) is cumbersome imho, so I'd just be content with this, which is probably okish for high enough bitrates [19:55:47 CET] <sfan5> just relying on the encoder exporting that informating (_N types) sounds fine to me [19:57:01 CET] <JEEB> yea [19:57:03 CET] <kurosu> yeah, but that won't help as much - but then I don't know all the settings for skip_loop_filter [19:57:35 CET] <sfan5> if you want to trade quality for speed you'd set skip_loop_filter=all anyway [19:57:38 CET] <kurosu> it <AV_DISCARD_ALL, = should be an unconditional return [19:57:57 CET] <kurosu> yeah [20:00:02 CET] <kurosu> I have an educated guess that ffmpeg (or libav or any derivative) hevc decoder is 10-20% slower than it could be [20:00:51 CET] <sfan5> wasn't it based on some external projects code? [20:01:04 CET] <kurosu> openhevc, but same problem there [20:01:27 CET] <kurosu> not for lack of simd, just inefficient code all around [20:01:28 CET] <JEEB> smarter did the original HEVC decoder, not openhevc -- IIRC [20:01:38 CET] <JEEB> but the lack of SIMD doesn't really help :P [20:02:03 CET] <kurosu> I don't think there's anything missing nowadays [20:02:16 CET] <kurosu> except maybe some avx2 for transforms mainly [20:02:23 CET] <durandal_1707> whats inefficient? [20:02:26 CET] <JEEB> IIRC there still are some intrinsics that nevcairiel applies [20:02:40 CET] <JEEB> parts of openhevc that were never finished for upstreaming [20:02:56 CET] <kurosu> oh, the intra [20:02:58 CET] <JEEB> (openhevc did work a lot on multiview and scalable coding and intrinsics IIRC) [20:03:15 CET] <kurosu> I don't think it matters much, probably <1% of profiling [20:03:35 CET] <kurosu> except if you only have intra frames, obviously [20:03:46 CET] <JEEB> well it seemed to be enough for some people at some point. haven't seen recent benchmarks [20:03:55 CET] <JEEB> most recent was by hanna I think [20:04:03 CET] <kurosu> ok [20:04:20 CET] <JEEB> also adding a lot of threads tends to help with the instability of the FPS in the decoding [20:04:32 CET] <JEEB> since you get the buffer of amount of threads [20:23:11 CET] <kurosu> JEEB, if you have recent benchmarks, I'd like to have a link [20:27:52 CET] <JEEB> kurosu: the most recent I remember is https://haasn.xyz/posts/2016-11-08-ffmpeg-hevc-decoding-benchmarks.html [20:29:36 CET] <kurosu> "the intra pred SIMD basically made no difference at all" [20:31:06 CET] <kurosu> and yeah, cabac is the killer here [20:31:39 CET] <kurosu> openhevc offers to move it to its own thread [20:31:53 CET] <JEEB> ah [20:31:56 CET] <JEEB> kind of makes sense [20:32:32 CET] <kurosu> yeah, but lots of efforts (need to buffer, add wait/report progress stuff and so on) and I don't know how much you gain [20:32:49 CET] <kurosu> maybe reasonable on high bitrate + high cpu count systems [20:32:50 CET] <JEEB> yup [20:33:08 CET] <JEEB> deffo complexity [20:34:03 CET] <kurosu> there was the patch series from some arm guy that was a reasonable improvement (3-5% overall?) but he was reluctant to work more on it afaik [20:34:17 CET] <kurosu> (for inclusion) [20:54:38 CET] <smarter> JEEB: I did the original HEVC decoder for libav as a gsoc project, at the end of the gsoc I could play I-frames [20:54:45 CET] <JEEB> yup [20:54:56 CET] <JEEB> and then rest of that year it was finished up [20:54:56 CET] <smarter> Then a bunch of people worked on implementing everything else [20:55:11 CET] <JEEB> plenty of people on the commit message :) [20:55:20 CET] <JEEB> even me because of random valgrinding :D [20:55:24 CET] <smarter> haha [21:10:47 CET] <SortaCore> why does -timeout on rtsp result in bind address error? [21:11:10 CET] <SortaCore> I saw a ffmpeg ticket with a fix, but apparently it wasn't approved [21:11:40 CET] <SortaCore> https://trac.ffmpeg.org/ticket/2294 [21:12:41 CET] <wm4> didn't open that link, but we don't accept patches on trac [21:13:03 CET] <SortaCore> yea, he was told to post to ML, but didn't [21:13:13 CET] <SortaCore> https://github.com/FFmpeg/FFmpeg/pull/91/commits/61139a7e3ad3827db30d244e58… [21:13:45 CET] <wm4> ... [21:13:51 CET] <wm4> we don't accept PRs either [21:13:57 CET] <SortaCore> boi [21:14:16 CET] <wm4> https://github.com/FFmpeg/FFmpeg/pull/153 [21:14:23 CET] <wm4> though that was after that [21:15:10 CET] <SortaCore> yea, that bug is ancient apparently [21:15:27 CET] <SortaCore> I wasn't asking for that fix to be added, I'm just wondering why it's not fixed at all [21:17:32 CET] <JEEB> SortaCore: nobody hit that same issue and nobody noticed the thing who cared enough [21:18:04 CET] <SortaCore> rip fam [21:18:22 CET] <omerjerk> xD [21:18:32 CET] <SortaCore> I'm gonna make tea and then endure the pain of trying to patch >.> [21:19:05 CET] <JEEB> but yea, FFmpeg does an awful lot of things and in the small amount of testing I've done with rtsp both at home and at the office this was never hit :P [21:19:18 CET] <JEEB> so it's completely possible that even within the small circle that has ever utilized RTSP [21:19:20 CET] <wm4> SortaCore: append .patch to the github commit URL, send as attachment to ffmpeg-devel [21:19:27 CET] <wm4> it's not hard even if people think that [21:19:32 CET] <wm4> that said, fuck mailing lists [21:19:43 CET] <JEEB> yea, esp. if people don't version their patches [21:19:55 CET] <SortaCore> my issue is with git itself [21:19:57 CET] <JEEB> I've had to try and make sure I grabbed the latest version of a patch when applying [21:20:20 CET] <SortaCore> plus in this fact the fix will probably be incompatible with current code [21:20:33 CET] <JEEB> yea, that's possible. if you actaully want to make it applicable to current HEAD [21:20:43 CET] <JEEB> depends on how many changes there have been since [21:20:49 CET] <JEEB> (for those files) [21:21:02 CET] <SortaCore> I've already modded current head, to make sure QSV only looks for hardware impl [21:21:22 CET] <SortaCore> there doesn't appear to be an option you can pass [21:21:41 CET] <SortaCore> so I just changed the enum from "impl any" to "impl any hardware" [21:22:12 CET] <JEEB> I think some hwaccel already had that as an option [21:22:31 CET] <JEEB> shouldn't be too hard to add an AVOption and then do an if/else thing [21:22:48 CET] <JEEB> use_hw_only ? ONE_ENUM : ANOTHER_ENUM [21:23:55 CET] <SortaCore> this would be good but I treat git like I do extracting snake venom for antidotes [21:24:24 CET] <SortaCore> I'm normally fixing everything, but git is intimidating [21:24:35 CET] <JEEB> yea, it can be [21:24:45 CET] <JEEB> and it definitely has the tools to shoot your own feet off [21:24:59 CET] <SortaCore> with C++ I could do that and not worry about other people [21:25:20 CET] <JEEB> well with git unless you force push you don't lose anything :) [21:25:21 CET] <SortaCore> but I'm a bit concerned I might somehow blow up everything [21:25:29 CET] <JEEB> I mean, remotely [21:25:34 CET] <SortaCore> overwrite the master branch with one file somehow [21:25:40 CET] <JEEB> in the worst case you fsck up your local repo [21:25:45 CET] <JEEB> and for local repo you have reflog [21:25:51 CET] <JEEB> which is the log of last N positions [21:26:11 CET] <SortaCore> no chance of screwing up ffmpeg remote then? [21:26:23 CET] <JEEB> unless you have push access, no [21:26:38 CET] <JEEB> (the URL is separate from the public clone one, too) [21:26:43 CET] <SortaCore> ok, that's reassuring [21:27:08 CET] <SortaCore> having said that, I'm now looking at the patch the guy submitted, and I can't see how it would fix anything [21:28:04 CET] <SortaCore> oh, he moved an if [21:28:23 CET] <JEEB> yea [21:28:25 CET] <SortaCore> I know how to move ifs! [21:28:34 CET] <JEEB> he stops setting |= RTSP_FLAG_LISTEN [21:28:40 CET] <JEEB> when timeout is >0 [21:28:44 CET] <SortaCore> *scuffling* *distant explosion* [21:28:47 CET] <SortaCore> there we go [21:47:15 CET] <SortaCore> actually, infinite timeout only makes sense when you're sending, not receiving [22:11:47 CET] <atomnuker> daddesio: ktnx, on a first look they all lgtm [22:11:56 CET] <atomnuker> not sure about the downmixing part though [22:12:11 CET] <atomnuker> does the decoder actually support downmixing? [22:12:39 CET] <atomnuker> afaik in libopus you can specify what to downmix to but here you can't [22:13:40 CET] <atomnuker> jamrial: do you think the doing saturation via packed functions (on scalars, so a mov + saturated add + a mov) would be faster than the C version? [22:13:54 CET] <atomnuker> on x86 that is, because there are no scalar saturation functions here [22:26:37 CET] <daddesio> atomnuker: My downmixing patch should be correct. Each Opus stream has 1 or 2 channels, so a multichannel OggOpus file contains multiple Opus streams. In FFmpeg, f->channels refers to the # of channels in the CELT frame (which is constrained to 1 or 2). [22:27:07 CET] <daddesio> actually, you might be right [22:27:18 CET] <daddesio> hold on [22:30:16 CET] <daddesio> Libav uses s->coded_channels an s->output_channels in the CeltFrame context. [22:32:31 CET] <daddesio> Ah yes, I used the wrong variable ! FFmpeg also has an f->decoded_channels. [22:32:49 CET] <daddesio> Let me verify that it's set to the number of FFmpeg output channels. [22:34:09 CET] <daddesio> atomnuker: f->decoded_channels is defined here https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/opus_celt.c#L806 [22:36:48 CET] <daddesio> Also, see this: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/opus_celt.c#L865 [22:37:17 CET] <daddesio> The patch should be correct if I change f->channels to f->output_channels. [22:37:50 CET] <daddesio> As long as output_channels is indeed set correctly. [22:41:05 CET] <jamrial> atomnuker: if you mean adding such a path in av_clip* functions, i don't know [22:42:38 CET] <SortaCore> hmm [22:42:51 CET] <SortaCore> I can't even use the io callback, the formatcontext doesn't exist yet [23:06:07 CET] <SortaCore> seems like VLC is also failing to open the stream [23:06:18 CET] <SortaCore> but nonetheless, if an error can occur, it must be detected [23:12:10 CET] <daddesio> atomnuker: unfortunately it may not be that simple... f->output_channels is still 2 even when I pass -ac 1 to ffmpeg. [23:14:28 CET] <SortaCore> there's a timeout limit of 1 minute somewhere in rtsp [23:14:33 CET] <SortaCore> that seems a little high [23:19:27 CET] <SortaCore> is there a way to pass interrupt_callback to avformat_open_input [23:19:53 CET] <SortaCore> because the formatcontext isn't valid before, and the open_input seems to be blocking indefinitely [23:20:14 CET] <SortaCore> the only idea I've come up with is an evil second thread [23:31:16 CET] <cone-899> ffmpeg 03Paul B Mahol 07master:225341b20de6: avfilter/vf_stack: always copy SAR from first input [23:31:22 CET] <nevcairiel> you can create a formatcontext before calling open_input [23:31:38 CET] <nevcairiel> it only creates one for you if you dont pass one in [23:32:10 CET] <nevcairiel> with avformat_alloc_context [23:38:57 CET] <SortaCore> ah, danke [23:54:52 CET] <Compn> jkqxz : ok, no problem. i have no problem with putting the headers in another repo, as long as people are happy :P [23:54:58 CET] <Compn> jkqxz : thanks for the reply. [00:00:00 CET] --- Sun Dec 3 2017

1 0

ffmpeg.log.20171202
by burek 03 Dec '17

03 Dec '17

[00:16:27 CET] <TAFB> how can I record "desktop audio" on windows. "ffmpeg -list_devices true -f dshow -i dummy" says no video/audio devices found. [00:19:47 CET] <TAFB> ahhh https://github.com/rdp/virtual-audio-capture-grabber-device might work [00:25:33 CET] <TAFB> ^^ works flawless, woot! [02:01:46 CET] <ElementalOrange> Should I be seeing 100% cpu usage with: ffmpeg -f lavfi -i testsrc2=size=4k -c:v ffv1 -f null - [02:04:49 CET] <ElementalOrange> actually I think -f null forces just decoding [02:05:41 CET] <ElementalOrange> though I don't see a performance difference with o.mkv [02:09:28 CET] <furq> ElementalOrange: it doesn't force just decoding [02:09:48 CET] <furq> you should see 100% on one core but idk how well ffv1 scales to multiple threads [02:09:49 CET] <atomnuker> ElementalOrange: its a bottleneck in the encoder [02:09:54 CET] <furq> it might be something you need to explicitly enable [02:10:09 CET] <ElementalOrange> How can I stress test to make sure FFmpeg will span all cores/threads [02:10:16 CET] <furq> probably x264 [02:10:24 CET] <atomnuker> ElementalOrange: use something like magicyuv or x264, yeah [02:10:40 CET] <furq> if you mean specifically with ffv1 then if it doesn't do it in that test then it won't in real life [02:10:49 CET] <furq> certainly not without bumping the number of slices [02:11:31 CET] <ElementalOrange> magicyuv pushes to 90% [02:11:47 CET] <ElementalOrange> oh wait [02:11:51 CET] <furq> is there a builtin magicyuv encoder now [02:11:54 CET] <ElementalOrange> back down to ~30% [02:11:54 CET] <furq> i'll have to check that out [02:13:14 CET] <ElementalOrange> I'd think the encoder would use 100% CPU, even if it is the bottleneck [02:13:38 CET] <klaxa> if you want you could scale on file level and just run multiple encoding jobs [02:14:21 CET] <furq> atomnuker: does ffv1 automatically set -threads [02:14:25 CET] <ElementalOrange> It's just confusing why FFmpeg is spanning multiple treads but not using 100% [02:14:25 CET] <atomnuker> ElementalOrange: the thing is that ffv1 isn't really true intra-only codec, afaik some parts of the entropy coder are required for the next frame [02:14:27 CET] <klaxa> depending on your input anyway [02:15:05 CET] <furq> ElementalOrange: it should hit high 90s with x264 [02:15:21 CET] <atomnuker> so one thread encoding a single frame has to block for a little while the previous thread completes what's needed [02:15:46 CET] <furq> does ffv1 have frame threading [02:15:53 CET] <atomnuker> yes it does [02:15:56 CET] <furq> is that new [02:15:59 CET] <atomnuker> nope [02:16:00 CET] <ElementalOrange> I thought it was slice only [02:16:02 CET] <furq> my 3.3 build claims it's slice only [02:16:19 CET] <atomnuker> ah, you're right [02:16:32 CET] <ElementalOrange> That wouldn't use 100% though? [02:16:42 CET] <furq> you may need to set -slices and -threads [02:16:51 CET] <furq> apparently -slices 30 is the maximum and then -threads is your cpu count obv [02:16:56 CET] <ElementalOrange> So x264 is the only codec that actually uses all the CPU? [02:17:11 CET] <furq> probably not the only codec but it's definitely one that has efficient frame threading [02:17:19 CET] <furq> that your build almost certainly has [02:17:50 CET] <furq> and also one that has multithreading that works without any tuning [02:17:52 CET] <ElementalOrange> but even if ffv1 is super inefficient, wouldn't it just take longer per slice but still use 100%? [02:18:35 CET] <ElementalOrange> not sure how much tuning is needed, I just grabbed the latest git and did a basic configure and make [02:19:38 CET] <ElementalOrange> -slices 30 -threads 8 pushes ffv1 into the 80s at least [02:19:43 CET] <furq> i meant tuning the options [02:19:53 CET] <furq> x264 will use all your cpu by default [02:21:04 CET] <ElementalOrange> -slices seems to be the key, -threads doesn't change much [02:22:22 CET] <furq> https://www.ffmpeg.org/ffmpeg-bitstream-filters.html#h264_005fmetadata [02:22:23 CET] <furq> ooo [02:22:24 CET] <furq> nice [02:22:35 CET] <furq> (this has nothing to do with your problem, i just noticed it in the changelog) [02:24:57 CET] <ElementalOrange> what the heck, -vf hqdn3d brings the usage down [02:26:07 CET] <atomnuker> lavfi doesn't have frame threading [02:26:18 CET] <atomnuker> only slice threading [02:26:26 CET] <furq> yeah filtering will sometimes introduce a big bottleneck [02:26:45 CET] <ElementalOrange> is slice horrible or something? shouldn't it still be using more than 20% on my 4 core 8 thread cpu [02:26:51 CET] <atomnuker> also stop using hqdn3d, its worse than nlemans [02:26:58 CET] <atomnuker> *nlmeans [02:26:59 CET] <TheRock> how is the 264 encoding actually developed [02:27:03 CET] <ElementalOrange> which gets .5fps [02:27:07 CET] <furq> do you have some suggested settings for nlmeans that aren't slow as shit [02:27:10 CET] <TheRock> only through reverse engineer or are there public documents [02:27:15 CET] <furq> the defaults seem pretty bad lol [02:27:17 CET] <atomnuker> ElementalOrange: the filter needs to support slice threading [02:27:24 CET] <atomnuker> which hqd3dn doesn't [02:27:41 CET] <furq> also is anyone working on opencl nlmeans [02:27:49 CET] <furq> vapoursynth has it and it seems to work well [02:28:06 CET] <ElementalOrange> furq: I started actually [02:28:12 CET] <furq> neat [02:28:28 CET] <ElementalOrange> furq: but I got side tracked seeing how much asm would get me [02:28:29 CET] <atomnuker> ElementalOrange: using the new opencl hwaccel? [02:28:47 CET] <furq> all i need then is frame threaded nnedi3 and i can ditch vapoursynth entirely [02:28:52 CET] <furq> fingers crossed! [02:29:11 CET] <furq> i am inhaling now and will exhale again when it's done [02:29:54 CET] <ElementalOrange> I think it could get quite a bit faster with SIMD. I'm not an expert on SIMD though so it will take time [02:30:22 CET] <furq> well yeah i don't mind going through vs now i've got it all set up [02:30:22 CET] <ElementalOrange> I still don't know if my build is broken though since I cannot get 100% [02:30:27 CET] <furq> but it'd be nice if i didn't have to [02:32:29 CET] <ElementalOrange> -vf noise says it supports slice threading but I'm still sitting at <40% usage [02:34:18 CET] <atomnuker> ElementalOrange: ffmpeg got support for opencl filters a few weeks ago you know [02:35:02 CET] <furq> was it that recently [02:35:17 CET] <ElementalOrange> it's had opencl for a while? [02:35:35 CET] <ElementalOrange> unsharp for example? [02:37:39 CET] <atomnuker> that support was crap [02:37:55 CET] <ElementalOrange> it's true [02:38:04 CET] <atomnuker> this one's new and supports interops so you can feed it in hardware decoded frames and it'll convert them to opencl and back [02:38:25 CET] <ElementalOrange> once I try asm I might circle back and add opencl [02:39:13 CET] <ElementalOrange> 12% CPU with: ffmpeg -f lavfi -i testsrc=size=4k -c:v mjpeg -y -f null -, does that seeem right? mjpeg has frame and slice [02:39:45 CET] <atomnuker> no, only the decoder suppors them [02:39:58 CET] <atomnuker> the encoder doesn't suppor threading (yet, it'd be trivial to add) [02:40:20 CET] <ElementalOrange> is the raw decoder threaded [02:40:53 CET] <ElementalOrange> answer: no [02:42:55 CET] <ElementalOrange> atomnuker: Are you sure about that? 'ffmpeg -encoders 2>/dev/null | grep mjpeg' shows 'VFS... mjpeg MJPEG (Motion JPEG)' [02:43:37 CET] <atomnuker> nervemind, I confused it with the decoder (which doesn't support threading) [02:46:34 CET] <ElementalOrange> The h264 decoder and the mjpeg encoder both support frame and slice threading, yet 'ffmpeg -i ~/tears_of_steel_1080p.mov -c:v mjpeg -f null -' is using 20% CPU [02:46:46 CET] <timelapse> Woah! I didn't know there would be this many people! [02:46:55 CET] <timelapse> Hello everyone [02:47:13 CET] <timelapse> I am using ffmpeg and I am getting " Last message repeated 5 times Past duration 0.999992 too large 2816kB time=00:00:09.68 bitrate=2381.0kbits/s dup=1 drop=0 speed=0.137x" is that good> [02:47:15 CET] <timelapse> *? [02:47:35 CET] <ElementalOrange> timelapse: You're overrunning your buffer [02:47:52 CET] <timelapse> ElementalOrange: Oh I see. How do I fix that problem? [02:52:49 CET] <ElementalOrange> apparently the tiff encoder will get >90% [02:53:07 CET] <timelapse> ElementalOrange: Interesting [02:53:23 CET] <ElementalOrange> timelapse: unrelated to your question [02:53:26 CET] <timelapse> ElementalOrange: What do you mean by that [02:53:30 CET] <timelapse> Oh alright [02:53:37 CET] <ElementalOrange> timelapse: https://trac.ffmpeg.org/wiki/StreamingGuide [02:53:44 CET] <timelapse> Thanks [02:55:24 CET] <timelapse> ElementalOrange: Will my video still be made if I leave ffmpeg the current way it is? [02:55:43 CET] <ElementalOrange> timelapse: Are you capturing live? [02:56:52 CET] <timelapse> ElementalOrange: No, I'm trying to make a timelapse out of images. Here's my command `"C:\Users\Owne\Desktop\ffmpeg\bin\ffmpeg" -r 45 -start_number 0 -i GROLElement3_%d.png -s 1280x720 -vcodec libx264 GROLElement3.mp4` [02:57:06 CET] <timelapse> The `'s are not in the command [02:59:31 CET] <timelapse> I just wish I could get it to make a timelapse video from the images [03:00:28 CET] <ElementalOrange> timelapse: is it not producing an output [03:02:57 CET] <timelapse> ElementalOrange: I got a video but it didn't show the images. I'll show you the console [03:05:21 CET] <timelapse> ElementalOrange: https://hastebin.com/helogujoha.pl [03:18:57 CET] <TAFB> when pulling 4k from an ip camera, is there a way to make it perfectly smooth? https://www.youtube.com/c/Skyviewelectronics/live [03:19:07 CET] <TAFB> using -c copy (no re-encoding) [03:27:58 CET] <timelapse> anyone know what I need to do? [03:28:16 CET] <timelapse> All help is greatly appreciated! [05:09:02 CET] <Fig1024> I'm using SDK to record h264 video. For some reason, when I play recorded file, it shows several broken frames at beginning - like keyframe error. But if I play same file again 2nd time, no problem. It's kind of random. I need ideas why that happens [05:33:22 CET] <timelapse> Anyone? [06:00:07 CET] <marianina8> Does anyone know how to extract embedded smpte 436m captions from an MXF file using ffmpeg? [06:03:46 CET] <TheRock> i dont know this but, i know how to convert mp4 to mp3 [06:04:09 CET] <marianina8> that's ok...do you know the best way to find out how to do it? [06:04:33 CET] <TheRock> yeah [06:04:45 CET] <TheRock> you write ffmpeg and then you try all parameter from a to z [06:05:05 CET] <marianina8> lol [06:05:46 CET] <TheRock> if you want i can also explin you how to reboot your computer [06:08:39 CET] <marianina8> I really just need to know how to extract and decode smpte 436m captions from MXF files...not reboot my computer ;) [06:09:36 CET] <TheRock> but i dont know this [06:09:40 CET] <TheRock> i can only tell you what i know [06:09:53 CET] <TheRock> sometimes, its better to choose what you can get [06:16:13 CET] <marianina8> :-) [06:17:59 CET] <TheRock> what ios your os marianina8 [06:18:18 CET] <TheRock> i will give you the command to shut yyour pcv off [06:57:41 CET] <TDLBallistic> hello [06:57:56 CET] <TDLBallistic> I was wondering if anyone was around to help? [08:17:20 CET] <timelapse> Hello [08:17:22 CET] <timelapse> Why am I getting this output and no video? https://hastebin.com/lupejahiqa.pl I am using FFMPEG [08:17:25 CET] <timelapse> Here's my command `"C:\Users\Owne\Desktop\ffmpeg\bin\ffmpeg" -r 45 -start_number 0 -i GROLElement3_%d.png -s 1280x720 -vcodec libx264 GROLElement3.mp4` [08:17:27 CET] <timelapse> Please tag me since so I see hear your message since it's 2AM over here and I'm very tired :) [08:17:37 CET] <timelapse> All help is greatly appreciated! [08:17:39 CET] <timelapse> Thanks! [09:49:32 CET] <sagax> hi all! [10:17:19 CET] <rendar> this is what i get after `apt-get install ffmpeg` on my rasp-pi: `E: Package 'ffmpeg' has no installation candidate` [10:17:20 CET] <rendar> why? [10:18:07 CET] <atomnuker> too old raspbian [10:18:44 CET] <rendar> atomnuker: dist-upgrade? [10:19:27 CET] <atomnuker> dunno how that works on rasbian, try it [11:11:57 CET] <sagax> why i got this? http://susepaste.org/21000489 [11:12:07 CET] <sagax> ffserver hold empty connection [13:26:06 CET] <kerio> why does the latest samba46 pull in CUPS [13:26:08 CET] <kerio> :| [13:26:22 CET] <kerio> and avahi-app [13:50:37 CET] <ayum> Hi, does anyone know why ffmpeg drop frames? I am using filter complex psnr to compare 2 real-time v4l2 streams, but seems ffmpeg drop many frames randomly [13:50:49 CET] <ayum> Can I force ffmpeg do not to drop frames? [13:55:23 CET] <JEEB> the API shouldn't but the ffmpeg.c vsync algo can be funky. so it depends. also are you sure those two v4l2 streams are in sync? [13:59:08 CET] <ayum> @JEEB, yes, I can confirm the 2 v4l2 stream is synchronized. because these 2 streams are come from SetTopBox [13:59:42 CET] <JEEB> how do you synchronize them when reading then with the v4l2 APIs? [14:01:03 CET] <JEEB> anyways, in theory ffmpeg.c shouldn't drop frames but you're dealing with a lot of funky stuff like whatever ffmpeg.c picks as the "vsync" mode, and then the filter chain. [14:01:22 CET] <ayum> @JEEB, you know ffmpeg does not supports read 2 v4l2 streams at same time. so I modified ffmpeg.c and v4l2.c, basically, I use multi-thread to open the v4l2 devices, and add a synchronization on v4l2 device's open function [14:02:27 CET] <ayum> If ffmpeg does not drop frames, then everything works greet. but if it drop frames, things becomes very bad. [14:02:50 CET] <JEEB> if you can code that much it might be worth it to drop ffmpeg.c and make your own API client [14:02:57 CET] <JEEB> that way you know what exactly it does [14:03:03 CET] <JEEB> ffmpeg.c tries to do too many things [14:03:18 CET] <JEEB> and then there's libavfilter [14:03:21 CET] <JEEB> with your filter chain [14:03:36 CET] <ayum> yeah, it's my current idea too. I want to find out where ffmpeg.c drop frames, and try fix it. or comment out the drop frames code [14:03:36 CET] <JEEB> what I'm trying to say is, at least find out which part is dropping your frames if you believe the frames are being dropped :P [14:03:40 CET] <JEEB> so up verbosity [14:03:57 CET] <ayum> @JEEB, yes, thanks [14:03:58 CET] <JEEB> -v verbose or -v debug [14:04:59 CET] <JEEB> but yea, -vsync controls the ffmpeg.c "vsync" mode and you've got stuff like -copyts [14:05:12 CET] <JEEB> you can ctrl+F https://www.ffmpeg.org/ffmpeg-all.html for documentation [14:05:17 CET] <JEEB> if you really want to poke around ffmpeg.c still [14:06:21 CET] <ayum> -loglevel verbose option is very useful than debug [14:06:31 CET] <JEEB> yes, debug has a _lot_ of stuff [14:06:38 CET] <JEEB> also ffmpeg.c has -debugts was it? [14:06:51 CET] <JEEB> ok, it was -debug_ts [14:07:12 CET] <JEEB> which adds some specific print-outs at different points of ffmpeg.c [14:07:58 CET] <JEEB> but yea, basically the FFmpeg *base* libraries (lavf/lavc) shouldn't drop your frames, but ffmpeg.c and lavfi are the question marks :P [14:08:26 CET] <JEEB> which is why in the end you often end up building your own API client [14:09:10 CET] <JEEB> because then you know your flow instead of having to look through WTF ffmpeg.c is doing at every point :) [14:09:29 CET] <kerio> dammit wrong window again [14:09:29 CET] <kerio> lmao [14:09:41 CET] <ayum> there is a if statement if ffmpeg.c, if (nb_frames == 0 && ost->last_dropped) { ... } this statement will print the drop frame message [14:09:56 CET] <JEEB> ayum: that's just for one dropping point [14:10:17 CET] <JEEB> although that might (?) be the only thing in ffmpeg.c [14:10:28 CET] <ayum> @JEEB, I think I need trace "ost->last_dropped" [14:10:39 CET] <JEEB> debug_ts should show the packets it's feeding and getting from lavfi [14:10:42 CET] <JEEB> and other parts [14:10:51 CET] <JEEB> anyways, godspeed :P [14:47:58 CET] <therage3> is https://trac.ffmpeg.org down? [14:49:06 CET] <JEEB> looks like it's at least having issues responding [14:49:19 CET] <zash> 503 Service Unavailable it says, after a while [14:49:30 CET] <durandal_170> its down [14:50:00 CET] <therage3> ok good, so it isn't me then [17:39:04 CET] <CCFL_Man> i use a osx 10.6.8 and in mplayer, mpeg4 decoding is slow and causes sync issues, but in quicktime, it deccodes really well [17:39:24 CET] <CCFL_Man> quicktime musy have a driver that uses hardware decoding, right? [18:02:05 CET] <SortaCore> or mplayer just uses a really poor software decoder, and quicktime uses a better software one [18:44:50 CET] <BtbN> 10.6 is ancient. Any modern player based on ffmpeg won't be able to use hardware acceleration there. [18:45:51 CET] <SortaCore> "Apple added Quick Sync support in OS X Mountain Lion (10.8) for AirPlay Mirroring, FaceTime and QuickTime X." [18:46:02 CET] <SortaCore> so ain't in OSX 10.6 [18:47:27 CET] <SortaCore> y tho [19:04:51 CET] <Intektor> I am trying to receive a udp stream with ffmpeg and output the h264 stream in .png images to stdout, but I can't find the right configuration, current call is: ffmpeg.exe -i udp:localhost:1234 -f image2pipe -c bmp - [19:05:19 CET] <DHE> udp://listenip:port [19:05:57 CET] <Intektor> sorry, I forgot the // but I have it in my program, that is not the problem [19:06:13 CET] <DHE> is the sender on the local system and sending to 127.0.0.1 [19:07:10 CET] <Intektor> yes, when I do it with ffplay it works just fine [19:07:31 CET] <Intektor> this si the log: https://pastebin.com/f9iZjuaC after this ffmpeg just freezes and doesnt repond anymore [19:09:24 CET] <elanozturk> hi all,im having "ERROR: opus not found using pkg-config" any advice to solve this,i am on 32 arm debian jessie [19:21:36 CET] <c3r1c3-Win> elanozturk: Do you have the Opus and Opus-devel packages installed? [19:25:30 CET] <elanozturk> i installed opus but its in different folder [19:25:44 CET] <slip> I joined 12 short videos but some reason there is no sound in some sections. How would I re-encode the only the sound using this [19:25:45 CET] <slip> ffmpeg -f concat -safe 0 -i mylist.txt -c copy output [19:25:45 CET] <JEEB> PKG_CONFIG_PATH=/path/to/opus/prefix/lib/pkgconfig [19:25:50 CET] <JEEB> when doing configure [19:25:51 CET] <JEEB> then [19:26:34 CET] <faLUCE> Hello. My library ( https://github.com/paolo-pr/laav ) uses FFMpeg. I chose the GPL 3.0 license and specified it in EACH file of the project. Please can you help me in checking if is it all ok or I have to add something more? [19:27:19 CET] <elanozturk> okay i will try that @c3r1c3-Win [19:27:22 CET] <elanozturk> thank you [19:28:43 CET] <faLUCE> obviously, all the source of my project is open. [19:29:35 CET] <faLUCE> I also ask if is it possible to link the library in the FFmpeg official page [19:29:38 CET] <slip> how can I re-encode the only the sound in my joined videos. Lots of clips with very different weird codecs. Want something that is simple and works with everything [19:29:39 CET] <slip> ffmpeg -f concat -safe 0 -i mylist.txt -c copy output [19:30:13 CET] <slip> the video should be just copied as is [19:30:22 CET] <sfan5> faLUCE, there's a checklist here http://ffmpeg.org/legal.html [19:32:22 CET] <c3r1c3-Win> slip: If you want something that works with 'everytihng' then you'll need to re-encode the video and audio to 1 codec. [19:32:54 CET] <c3r1c3-Win> *everything [19:34:03 CET] <slip> c3r1c3-Win, the video is already x264 and seems to have been done with ffmpeg. [19:34:41 CET] <slip> c3r1c3-Win, so I need to re-encode it too? [19:35:08 CET] <faLUCE> sfan5: I know that. But it says few things about GPL. All the source of my library is open and I added the GPL 3.0 and later notice in each file of the project. Is it enough or do I have to add something more? [19:35:40 CET] <slip> c3r1c3-Win, I can stick it in ally old container I guess such as mkv [19:36:37 CET] <sfan5> faLUCE, your application does not need to be GPL to be able to link to ffmpeg [19:36:55 CET] <faLUCE> sfan5: why not? [19:36:57 CET] <JEEB> faLUCE: your license doesn't matter too much as long as you adhere to FFmpeg's licensing. Which usually happens during distribution of binaries [19:37:12 CET] <sfan5> ^ [19:37:17 CET] <c3r1c3-Win> slip: I'm not an ffmpeg expert, but from your description it seems like you have a single file that on thevideo side is encoded with x264 but the audio part has sections that are missing. If that's the case then it seems that the audio would be missing, which means starting from square one, and re-encoding the original files in one codec. [19:37:39 CET] <JEEB> now of course if you made a closed source thing, and linked against GPL FFmpeg then you need to make ALL THINGS *also* available as GPL [19:37:45 CET] <JEEB> this is what some companies have had to do [19:38:23 CET] <faLUCE> JEEB: sfan5, then, without binaries I don't have any issue, right? [19:38:38 CET] <JEEB> generally yea [19:39:03 CET] <faLUCE> JEEB: that's much better, because I like OPEN SOURCE software [19:39:33 CET] <JEEB> basically if you're using FFmpeg you just have to adhere to FFmpeg's license [19:39:41 CET] <JEEB> FFmpeg can be configured to be either LGPL (default) or GPL [19:40:36 CET] <faLUCE> JEEB: given that all is header and no binaries, this is an automatic thing [19:40:55 CET] <JEEB> well yes, I'm just saying :P [19:41:05 CET] <faLUCE> JEEB: thanks [19:41:45 CET] <JEEB> although do remember that if your thing is GPLv3 then in general that means that anything utilizing your header has to (also) be under GPLv3 [19:42:06 CET] <faLUCE> JEEB: of course. In fact I want it open source [19:42:15 CET] <Toba> but do you want it gplv3 [19:42:27 CET] <JEEB> also do note that v3 means that you cannot link against things that are v2 only [19:42:30 CET] <Toba> ^ [19:42:43 CET] <faLUCE> JEEB: what is v2 in ffmpeg? [19:43:02 CET] <Toba> gpl v2 [19:43:05 CET] <JEEB> haven't looked at the dependencies [19:43:26 CET] <JEEB> I would think that most of the GPL stuff in FFmpeg itself is "or later", but I have no idea about dependencies :P [19:43:59 CET] <faLUCE> JEEB: I use x264, MJPEG, MP2 and AAC codecs [19:45:07 CET] <faLUCE> https://www.ffmpeg.org/doxygen/0.6/mjpeg_8c-source.html <--- this is mjpeg (It says lgpl 2 or later) [19:45:48 CET] <slip> One of my clips give me this. The other 11 are fine [19:45:49 CET] <slip> Error while decoding stream #0:1: Invalid data found when processing input [19:45:49 CET] <slip> [aac @ 0x560ec729fe40] Number of bands (51) exceeds limit (40). [19:46:01 CET] <slip> what does this mean? [19:46:41 CET] <faLUCE> what about aac ? [19:47:01 CET] <slip> I am using $ ffmpeg --version [19:47:01 CET] <slip> ffmpeg version 3.2.9-1~deb9u1 Copyright (c) 2000-2017 the FFmpeg developers [19:47:01 CET] <slip> built with gcc 6.3.0 (Debian 6.3.0-18) 20170516 [19:47:36 CET] <JEEB> faLUCE: if it's internal it's most likely LGPLv2+ [19:47:44 CET] <c3r1c3-Win> slip: A quick Google search of that error message shows that it's a corrupt/damaged AAC track/file. [19:47:54 CET] <JEEB> so if you're only using x264 which is GPLv2+ IIRC [19:48:03 CET] <JEEB> although let me check that... [19:48:28 CET] <JEEB> oh [19:48:32 CET] <JEEB> GPLv2 only? [19:48:39 CET] <JEEB> http://git.videolan.org/?p=x264.git;a=blob;f=COPYING;h=d60c31a97a544b530390… [19:48:46 CET] <JEEB> ctrl+F "or la" [19:48:47 CET] <slip> c3r1c3-Win, thx. Ill fix that clip then. Since I only use stuff in Debian stable/main repos was wondering if it was a codec issue [19:48:49 CET] <JEEB> doesn't give anything [19:49:01 CET] <JEEB> oh nope [19:49:07 CET] <JEEB> it was "any later" [19:49:12 CET] <JEEB> so it was how I remembered [19:49:15 CET] <JEEB> GPLV2+ [19:49:47 CET] <faLUCE> JEEB: so is it ok with 3.0 ? [19:50:06 CET] <JEEB> yes [19:50:12 CET] <faLUCE> and what about aac ? [19:50:25 CET] <JEEB> if you mean the internal ffaac then that's LGPLv2 [19:50:42 CET] <faLUCE> JEEB: and later? [19:50:45 CET] <JEEB> yes [19:50:57 CET] <faLUCE> so, is it compatible with gpl 3.0? [19:51:04 CET] <JEEB> if you mean the internal ffaac, yes [19:51:20 CET] <faLUCE> has it the same API as libfdk-aac ? [19:51:21 CET] <JEEB> what I meant is that you should look if any of the libraries you link against are v2 only [19:51:31 CET] <JEEB> faLUCE: what? [19:51:45 CET] <JEEB> of course not, fdk-aac is a separate library. through avcodec they are the same for you though. [19:51:58 CET] <JEEB> also fdk-aac is enable-nonfree so it is not compatible with LGPLv2+ [19:52:10 CET] <faLUCE> JEEB: exactly, so, the API is the same for the internal aac [19:52:37 CET] <JEEB> jesus christ... [19:52:47 CET] <JEEB> for an external API user they are utilized in the same way [19:52:48 CET] <JEEB> yes [19:52:55 CET] <faLUCE> ok [19:53:00 CET] <JEEB> (external API user of avcodec, that is) [19:53:03 CET] <JEEB> that is what I meant [19:53:13 CET] <JEEB> but fdk-aac generally means that the binaries you cannot distribute [19:53:16 CET] <JEEB> it requires enable-nonfree [19:53:24 CET] <BtbN> JEEB, fdk-aac is only non-free in an --enable-gpl build. [19:53:49 CET] <BtbN> LGPL is fine with its license. [19:53:49 CET] <JEEB> that is kind of what I was thinking but I think FFmpeg's configure always requires nonfree? [19:53:59 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/configure#L3768 [19:54:00 CET] <BtbN> it doesn't [19:54:07 CET] <JEEB> I stand corrected then [19:54:08 CET] <JEEB> :) [19:54:18 CET] <BtbN> --enable-gpl is just very common, due to x264 [19:54:27 CET] <BtbN> so a build with x264 and fdk-aac will always be non-free [19:54:28 CET] <JEEB> but yea, I had I think voiced that before [19:54:42 CET] <faLUCE> now, the last question is: I used libevent, which is 3-clause BSD license. It says that it is GPL compatible. But, is it compatible with GPL 3.0 too? [19:54:42 CET] <JEEB> because LGPL lets you link against OSS as a nonfree thing [19:54:52 CET] <JEEB> yes [19:55:10 CET] <faLUCE> JEEB: was this yes to my question? [19:55:14 CET] <JEEB> yes [19:55:16 CET] <faLUCE> ok thanks [19:57:47 CET] <faLUCE> what about MP2 ? [19:57:59 CET] <faLUCE> I can't find the header of the mp2 encoder [19:58:37 CET] <JEEB> if it's internal to FFmpeg and doesn't get disabled with enable-version3 (not sure we have any such?) then it should be [20:00:00 CET] <CCFL_Man> SortaCore: yeah, there is only mpeg4 hardware decoding in quicktime available on osx 10.6 only. later versions allow other software to use it [20:01:12 CET] <CCFL_Man> so i'll have to use ffmpeg to transcode to mp4 [20:01:24 CET] <CCFL_Man> quicktime does not like ac3 audio either [20:01:41 CET] <faLUCE> JEEB: I found mp3enc.c, which includes mp2. It uses lgpl 2 or later, so for GPL 3.0 it is ok, right? [20:01:44 CET] <CCFL_Man> that needs to be transcoded to aac [20:09:49 CET] <eckynas> so i have this ancient video file with corrupted video part [20:09:55 CET] <eckynas> but the audio still sounds good [20:10:08 CET] <eckynas> is there a way to get rid of the video from the file and just keep the music? [20:10:28 CET] <therage3> eckynas: use something like 'ffmpeg -i input -vn -acodec copy output' [20:11:10 CET] <CCFL_Man> Program 1 Stream #0:0[0xf41]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], Closed Captions, 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc [20:11:17 CET] <eckynas> no that cant be right [20:11:37 CET] <eckynas> that copies the stream to a new file right? [20:12:15 CET] <therage3> the audio stream solely, yes [20:12:19 CET] <therage3> that's what you wanted, right? [20:12:26 CET] <therage3> since the video is corrupted [20:12:39 CET] <eckynas> is there a way to get rid of the video from the file and just keep the music? [20:12:49 CET] Action: therage3 blinks [20:12:58 CET] <therage3> i just told you which command you need [20:13:15 CET] <eckynas> no that doesnt seem right sorry [20:13:36 CET] <eckynas> what i want to do is get rid of the video stream from this original file and just retain the audio stream [20:13:48 CET] Action: therage3 blinks [20:14:20 CET] <therage3> ok, so if you take the audio stream and copy it solely to a new file, how precisely does that differ from what you want? [20:14:50 CET] <eckynas> i cant see how its actually any different but it doesnt sound right sorry [20:15:49 CET] <klaxa> +(-3) is no different from -3 [20:15:54 CET] <klaxa> it's the same operation [20:16:15 CET] <eckynas> i dont see what that has to do with anything [20:16:16 CET] <klaxa> same with either "dropping video" and "retaining only audio" [20:16:54 CET] <therage3> ok, you want to get rid of the video stream from your file and retain only audio. the method i suggested is to copy just the audio stream to a new file [20:16:59 CET] <therage3> the end result is the exact same thing [20:18:49 CET] <eckynas> is there anyone else here that can help? i kind of expected a serious response [20:18:57 CET] <eckynas> not condescension [20:19:41 CET] <sfan5> wat [20:19:45 CET] <therage3> you know, in other channels a more appropriate response would be "thanks for the free help" [20:20:07 CET] <CCFL_Man> eckynas: his was a serious response [20:20:37 CET] <eckynas> CCFL_Man: it sounds like a really hacky quick way of doing it [20:20:43 CET] <eckynas> it doesnt seem very thought out [20:21:43 CET] <eckynas> therage3 can you stop interacting with me? i dont need some neckbeard getting bent out of shape for being wrong [20:21:53 CET] <therage3> :| [20:23:21 CET] <Kuukunen> the downside of using a free product instead of a paid one with a contract is that to get support you have to be a decent human being [20:23:40 CET] <Kuukunen> don't worry, I hate that too, [20:23:57 CET] <eckynas> i know right? [20:24:11 CET] <eckynas> god i hate that about foss culture [20:24:38 CET] <eckynas> it isnt the first time i come to a support channel and the whole place gangs up on me because i point out an obviously idiotic response [20:24:56 CET] <Kuukunen> yea, in my company I enjoy treating my employees like shit [20:25:15 CET] <sfan5> i can't tell if this is bait [20:25:28 CET] <Kuukunen> I mean, I'm me, and they're not me, so why should I respect them? :o [20:25:46 CET] <therage3> sfan5: I started ignoring them a while ago, whether it's bait or not, free support volunteers do not have to put up with that sort of attitude [20:25:58 CET] <sfan5> true [20:26:07 CET] <eckynas> excuse me? attitude? [20:26:28 CET] <Kuukunen> frankly I'm surprised eckynas hasn't gotten kickbanned yet [20:26:38 CET] <eckynas> the hell is this guy's problem? [20:27:16 CET] <durandal_1707> eckynas: which format you need? [20:27:29 CET] <eckynas> durandal_1707 well this is a vob file copied from a dvd [20:28:14 CET] <eckynas> durandal_1707 i was hoping to get it into an mp3 losslessly [20:28:29 CET] <therage3> ... an MP3? _losslessly_??? [20:28:32 CET] <durandal_1707> only if vob track is mp3 [20:28:53 CET] <eckynas> no its ac3 i think [20:29:15 CET] <therage3> then an mp3 transcode will make it lose quality, you either need to use FLAC or copy it [20:29:22 CET] <eckynas> omfg [20:29:27 CET] <eckynas> will you stop talking to me already [20:29:33 CET] <therage3> ok, jeez [20:29:49 CET] <CCFL_Man> eckynas: you are not a good person [20:30:04 CET] <CCFL_Man> what he did accomplished exactly what you wanted [20:30:17 CET] <eckynas> this is the ganging up i was talking about before [20:30:26 CET] <CCFL_Man> 'ffmpeg -i input -vn -acodec copy output' [20:31:10 CET] <durandal_1707> for lossless just copy to ac3 or transcode to lossless audio format [20:31:32 CET] <eckynas> isnt that exactly what therage3 said durandal_1707?? [20:33:00 CET] <eckynas> i dont know why this is so difficult [20:33:09 CET] <eckynas> all i want is to use ffmpeg to get rid of the video part of this file [20:33:11 CET] <durandal_1707> yes, there is no other way, except stoling dvd master and transcoding to mp3 [20:33:47 CET] <CCFL_Man> eckynas: 'ffmpeg -i input -vn -acodec copy output file.file' [20:34:15 CET] <eckynas> dude i saw that the first time i dont want to copy the audio stream [20:34:18 CET] <durandal_1707> no need to repeat stuff already told [20:34:29 CET] <CCFL_Man> that is the only way to do it [20:34:31 CET] <eckynas> how do i strip the video from it [20:34:44 CET] <CCFL_Man> by creating a copy without it [20:34:56 CET] <CCFL_Man> that's how computers work [20:35:08 CET] <eckynas> so i cant physically edit the file and remove the video stream and save it that way? [20:35:19 CET] <furq> no [20:35:26 CET] <CCFL_Man> nein [20:35:29 CET] <furq> certainly not with ffmpeg because that doesn't support any inplace editing at all [20:35:38 CET] <furq> but i doubt any other tool will do it in this case [20:35:48 CET] <eckynas> why the fuck didnt anyone say that before? all i got was a bunch of commands and condescension [20:35:55 CET] <sfan5> lmao [20:38:36 CET] <eckynas> what the hell is so funny? [20:38:54 CET] <sfan5> oh nothing [20:39:54 CET] <CCFL_Man> eckynas: are you one of those point and click kiddies? [20:40:25 CET] <eckynas> if i'm in an ffmpeg channel which is a command line utility, why would you even ask me that [20:40:38 CET] <tdr> i think you should realize that not all advise probably has the condescending tone you read it as having, most folks just try to help [20:41:38 CET] <eckynas> tdr scroll up and read what therage3 was saying [20:43:11 CET] <tdr> eckynas, gotcha, just /ignore the folks you aren't liking the answers from, its the most powerful tool on irc [20:43:42 CET] <eckynas> tdr he was on my ass ever since i joined the channel and then CCFL_Man followed up [20:44:42 CET] <tdr> eckynas, ok then /ignore the user ... no one needs hounded, but the following rants or whatever arent needed either. dont give the reaction, just ignore whoever [20:45:09 CET] <eckynas> they kept spamming some bullshit random command and then only after some prodding and digging i managed to unveil that ffmpeg doesnt work that way with streams [20:46:23 CET] <durandal_1707> eckynas: why it must be inplace? [20:47:06 CET] <eckynas> it isnt that it must be in place, i just assumed thats how it worked, so when people suggested i copy the streams instead of in place edit it seemed off and wrong to me [20:47:11 CET] <tdr> afaik not many things would do an edit liek that on a file [20:47:36 CET] <tdr> most would at least use a temp file then replace original with the result [20:48:56 CET] <eckynas> jesus christ here we go again with the temp file nonsense [20:49:45 CET] <tdr> eckynas, simply stating very few things would NOT use a temp file of some sort for that. doing it in-place isn't how most things do it [20:50:11 CET] <tdr> the profanity wont earn you more help points or code changes either. [20:51:04 CET] <therage3> I'd just ignore them because they're either baiting or aren't willing to be helped, and they're only making the channel a hostile, uncomfortable place [20:51:18 CET] <eckynas> what the fuck [20:51:20 CET] <eckynas> this guy again [20:51:22 CET] <eckynas> DUDE [20:51:26 CET] <eckynas> get out of my face already [20:51:54 CET] <CCFL_Man> eckynas: you have received the solution. please leave [20:52:19 CET] <eckynas> that will happen when i quit my client, and i decide that, not you [20:52:32 CET] <CCFL_Man> fair enough [20:52:46 CET] <therage3> it can also happen when a moderator has had enough of your nonsense, and I'm surprised you're still not kickbanned. [20:54:20 CET] <eckynas> im making the channel a hostile uncomfortable place? [20:54:24 CET] <eckynas> the fuck you talking about [20:54:56 CET] <eckynas> i asked one simple question [20:55:02 CET] <eckynas> and you fuckers turned it into an inquisition [20:55:25 CET] <eckynas> it was one motherfucking simple question [20:56:19 CET] <Kuukunen> aww, I was just writing a very witty line :< [20:56:34 CET] <therage3> Good riddance as far as i'm concerned [20:56:44 CET] <sfan5> it has to be bait at this point [20:56:48 CET] <Kuukunen> well of course [20:57:04 CET] <therage3> either that, or he had severe emotional intelligence/impulse control issues [20:57:16 CET] <Kuukunen> sfan5: don't think so, there's lots of people like that [20:57:45 CET] <sfan5> Kuukunen, i have never met such people irl so i'd like to believe that there isn't [20:57:51 CET] <sfan5> unfortunately you're probably right [20:57:59 CET] <Kuukunen> I was just writing that he sounds like the k7nd of a person that really enjoys being shitty at customer support people [20:58:12 CET] <therage3> sfan5: to be fair, the anonymity of IRC/inability to physically confront people makes people like that act more than usual [20:58:21 CET] <Kuukunen> and the support just has to take it because he's a paying customer [20:58:31 CET] <therage3> if he talked liked that to people in real life, a couple of fat lip incidents would know the idiocy right out of him [20:58:39 CET] <therage3> knock* [21:09:54 CET] <SortaCore> sounds like a talk I had with an autistic guy [21:10:08 CET] <SortaCore> he had this locked visualisation of how a thing should be done [21:10:14 CET] <SortaCore> yet could not explain why it must be done that way [21:10:26 CET] <SortaCore> he was more polite about it, though [21:11:36 CET] <therage3> there's a difference between being autistic and being a <censored> [21:12:03 CET] <therage3> people with autism can't help, it's how they are and it is not their fault -- a person with a bad attitude on the other hand has control over their impulses [21:12:12 CET] <therage3> this guy had a bad attitude [21:12:54 CET] <tdr> if the mentally ill were too all be banned from irc, who would be left? [21:13:03 CET] <therage3> o.o [21:13:04 CET] <furq> just me [21:13:12 CET] <furq> that is a dream i often have [21:13:26 CET] <tdr> or a narcissistic delusion :) [21:13:26 CET] <therage3> being alone on IRC? [21:17:40 CET] <c3r1c3-Win> I would still be here. ;-) [23:40:56 CET] <Intektor> Hey I am trying to stream with ffmpeg using udp, when I receive the stream with ffplay its very beautiful and fine, but when I use vlc the image is really bad and it seems to be missing frames and it repeats frames, what can I be doing wrong? [23:42:58 CET] <Intektor> ffmpeg -framerate 60 -i image2pipe -force_key_frames "expr:gte(t,n_forced*2)" -pix_fmt yuv420p -tune zerolatency -preset ultrafast -f mpegts -profile baseline -c:v libx264 -crf 21 udp://localhost:1234 [00:00:00 CET] --- Sun Dec 3 2017

1 0

ffmpeg-devel.log.20171201
by burek 02 Dec '17

02 Dec '17

[00:07:45 CET] <durandal_1707> jamrial: that is something else, for alternating stuff [00:08:42 CET] <JEEB> yhttp://up-cat.net/p/d1a1da67 [00:08:46 CET] <JEEB> http://up-cat.net/p/d1a1da67 [00:08:51 CET] <JEEB> anyone else seeing this stuff? [00:09:39 CET] <cone-225> ffmpeg 03John Stebbins 07master:2d015d3bf9fe: lavf/mov: fix huge alloc in mov_read_ctts [00:09:40 CET] <jamrial> durandal_1707: can't you use it to choose between ALTERNATING_LR and ALTERNATING_RL when the side data is AV_STEREO3D_FRAMESEQUENCE? [00:10:11 CET] <JEEB> http://up-cat.net/p/7b1c1582 [00:10:12 CET] <JEEB> oh fun [00:10:22 CET] <jamrial> maybe also others [00:10:26 CET] <JEEB> now failure with gcc [00:11:15 CET] <durandal_1707> jamrial: yes, but there is yet another field iirc [00:11:59 CET] <jamrial> JEEB: the android fate client in fate.ffmpeg.org is broken for a different reason, so guess that's why nobody noticed it [00:13:25 CET] <JEEB> yea, the mediacodec one is definitely breakage in general, the NEON asm is clang-specific (with gas-preprocessor), as GOOG has recommended clang for quite a while now [00:14:55 CET] <jamrial> JEEB: try including hwaccel.h in that mediacodec file [00:16:27 CET] <JEEB> seems to have fixed it [00:16:56 CET] <JEEB> I guess the moving of the hwaccel stuff derp'd it [00:18:57 CET] <JEEB> jamrial: yes, that links [00:20:04 CET] <jcdutton> tmm1, just submitted it. How do I find out if it will be accepted or not? [00:23:47 CET] <tmm1> jcdutton: you should get some replies to the patch with any review and then someone (the maintainer of that codec probably) will apply and reply [00:25:09 CET] <jcdutton> Ok. It is only something small. It adds to the segment muxer so that files are put in subdirectories by date. [00:25:48 CET] <cone-225> ffmpeg 03Jacob Trimble 07master:83ecdc9a920d: configure: Fix dependencies of aac_at decoder. [00:34:51 CET] <jamrial> fuck that december email messing my inbox [00:36:34 CET] <wm4> heh [00:38:51 CET] <StevenLi_> jamrial: why the libavutil/reverse.c don't move to the libavutil/reverse.h? [00:40:03 CET] <StevenLi_> i see there is an array. and just extern it in the libavutil/reverse.h, but the commit http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=3cd616a0c95853411f6ab2… there have a c source include the other c source. [00:40:53 CET] <jamrial> StevenLi_: shared builds needed that [00:41:15 CET] <jamrial> mmh, i think we could replace the uglyness with av_export_avutil [00:42:53 CET] <StevenLi_> ok, Thanks :D [00:58:50 CET] <SortaCore> tmm1: do you use the same hwa context for both decoder + encoder when transcoding? [00:58:55 CET] <SortaCore> for hw_device_ctx [01:37:06 CET] <atomnuker> daddesio: huh, send a patch and I'll review it [01:57:09 CET] <daddesio> atomnuker: Will do. I'll try to get my patches posted on the ML by tonight. [03:08:47 CET] <daddesio> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/opus_silk.c#L65 [03:11:08 CET] <daddesio> ^ That loop simply determines if there are any NLSFs with a "negative min_diff" (i.e. is too close to the previous NLSF) and if so, sets k to the one that has the worst min_diff--otherwise, the function returns. [03:11:38 CET] <daddesio> However, the "if (pass == 20) break;" is never true and can be removed. (I double-checked against the original libopus code.) [03:13:08 CET] <atomnuker> go ahead and remove it then [03:13:28 CET] <daddesio> set k to 0 as well to silence the warning? [03:13:39 CET] <daddesio> I should add a comment too about what the loop is doing. [03:15:32 CET] <Compn> wm4 : question, why not fork chromiums' fork of ffmpeg ? since its just decoders and just for the top 10 formats or whatever... [03:15:45 CET] <wm4> ? [03:15:55 CET] <Compn> instead of the full ffmpeg with encoders [03:16:55 CET] <Compn> seems easier to maintain a smaller codebase [03:16:58 CET] <Compn> than 1 million LOC [03:17:22 CET] <Compn> especially for mpv, which is player only? [03:17:46 CET] <wm4> I have no idea what you're trying to do [03:17:55 CET] <Compn> im just asking a qquestion [03:18:11 CET] <Compn> maybe i misunderstand your situation [03:29:26 CET] <atomnuker> daddesio: if you want to, I don't mind [03:39:42 CET] <SortaCore> do you use the same hw_device_ctx in both decoder/encoder when transcoding? [05:16:49 CET] <atomnuker> michaelni: gcc 4.9 compiles the first patch just fine [05:22:16 CET] <jamrial> atomnuker: that's because 4.9 is the first version with c11 atomics support [05:22:38 CET] <jamrial> 4.8 and older use the compat code [05:30:50 CET] <wm4> amazingly late [05:30:57 CET] <wm4> how's clang support? [05:31:02 CET] <wm4> and msvc? (ok, lol) [05:31:34 CET] <cone-508> ffmpeg 03Dale Curtis 07release/3.4:ceed79323cb0: Don't manipulate duration when it's AV_NOPTS_VALUE. [05:31:34 CET] <cone-508> ffmpeg 03Jacob Trimble 07release/3.4:5ab992cd3875: configure: Fix dependencies of aac_at decoder. [05:31:34 CET] <cone-508> ffmpeg 03James Almer 07release/3.4:8d51090dcb8b: avformat/matroskaenc: actually enforce the stream limit [05:31:34 CET] <cone-508> ffmpeg 03James Almer 07release/3.4:2940b3e17cd3: avformat/matroskaenc: add missing allocation failure checks for stream durations [05:31:34 CET] <cone-508> ffmpeg 03James Almer 07release/3.4:bcfbcbec481c: avcodec/proresdec: align dequantization matrix buffers [05:31:47 CET] <atomnuker> clang took longer, wasn't until 4.0 or 5.0 that it got stdatomic.h [05:37:49 CET] <cone-508> ffmpeg 03James Almer 07master:5e9b39b37321: avcodec/h264_sei: remove redundant prefix to H264SEIFramePacking fields [05:37:50 CET] <cone-508> ffmpeg 03James Almer 07master:e01d2c00ae07: avcodec/h264_slice: use H264_SEI_FpaType enum constants [10:43:12 CET] <nevcairiel> wm4: msvc has the c++ stdatomic, which basically follow the same syntax just with c++isms (and afaik was the template for the C implementation in the first place), i always wondered why they dont just provide it in C as well, but its not a key focus for them [10:57:56 CET] <cone-502> ffmpeg 03Paul B Mahol 07master:2cfc8b172ce7: avfilter/vf_tile: add init_padding option [12:40:45 CET] <durandal_1707> kierank: what do you think about filter that detects telecine patterns in video? [12:42:14 CET] <nevcairiel> dont we have that [12:42:21 CET] <JEEB> I would think that generally is something the fieldmatch filter should be doing [12:46:18 CET] <nevcairiel> yeah thats the one [12:46:28 CET] <nevcairiel> paired with decimate to actually get rid of the repeated fields if wanted [12:50:52 CET] <durandal_1707> fieldmatch changes video [12:55:48 CET] <JEEB> durandal_1707: well you in the end want to do the IVTC [12:56:02 CET] <JEEB> otherwise why would you be doing the telecine pattern searches? [12:56:10 CET] <JEEB> what is the use case for *only* doing the pattern search [12:57:51 CET] <nevcairiel> you would basically re-write fieldmatch anyway, with all the detection just without the field reconstruction [12:58:44 CET] <durandal_1707> you guys dont get it [13:00:52 CET] <nevcairiel> thats because you dont say more then two words =p [15:17:02 CET] <ubitux> is the matroska muxer braindead wrt time base? [15:17:53 CET] <ubitux> ffmpeg -f lavfi -i testsrc2=r=60:d=1 -y /tmp/media.mp4 [15:17:56 CET] <ubitux> vs [15:17:58 CET] <ubitux> ffmpeg -f lavfi -i testsrc2=r=60:d=1 -y /tmp/media.mkv [15:18:44 CET] <iive> afair mkv has timebase in ms [15:18:56 CET] <ubitux> pts have a waaay too low resolution in mkv [15:20:20 CET] <ubitux> ffprobe -of flat -show_entries packet=pts /tmp/media.mp4 [15:20:32 CET] <ubitux> ffprobe -of flat -show_entries packet=pts /tmp/media.mkv [15:20:55 CET] <ubitux> that's a really low resolution [15:21:09 CET] <ubitux> iive: ms as in millisecond, not microsecond, right? [15:21:21 CET] <iive> 1/1000 s [15:21:27 CET] <ubitux> yeah, milli [15:21:37 CET] <ubitux> dammit, i shouldn't use mkv [15:21:47 CET] <iive> :) use nut :D [15:22:49 CET] <ubitux> i guess it's fine for animes with their 15 fps [15:59:33 CET] <StevenLi_> Hello ? [15:59:37 CET] <StevenLi_> How should i find the git-2014-11-19-6a054a4 source commit? [16:00:16 CET] <StevenLi_> i cannot find the 6a054a4 commit id at the newset git clone [16:02:13 CET] <StevenLi_> or that comiit have been removed? [16:02:30 CET] <StevenLi_> s/comiit/commit/g [16:02:32 CET] <jdarnley> I don't think we have ever altered history in the official repository [16:04:25 CET] <StevenLi_> Yes, i don't think so, but there really have no this commit [16:05:19 CET] <StevenLi_> https://www.pconlife.com/viewfileinfo/swresample-1-dll/ [16:05:29 CET] <jdarnley> I assume that hash is part of someone's private tree. [16:06:08 CET] <StevenLi_> Oh, i see, thanks, let me find it on other private tree :D [16:06:36 CET] <jdarnley> Why that has and not any of the others that look more like how FFmpeg formats its version numbers? [16:06:45 CET] <jdarnley> git log --before=2014-11-20 [16:06:58 CET] <jdarnley> (related but I meant these...) [16:07:00 CET] <jdarnley> N-71262-g511585c [16:07:05 CET] <jdarnley> N-65738-g3c197442 [16:07:14 CET] <jdarnley> N-67999-gd0879a9 [16:07:20 CET] <jdarnley> N-65810-g1b5ec6a [16:07:27 CET] <jdarnley> N-70239-g111d79a [16:07:45 CET] <StevenLi_> Thanks [16:08:05 CET] <jdarnley> commit 511585ce7f [16:08:05 CET] <jdarnley> Author: wm4 <nfxjfg(a)googlemail.com> [16:08:05 CET] <jdarnley> Date: Fri Apr 3 16:11:53 2015 +0200 [16:08:52 CET] <StevenLi_> yes, i know this, on ffbuild/version.sh [16:10:42 CET] <iive> jdarnley: we've done once or twice. the first time was shortly after the project moved to git.. [16:11:13 CET] <jdarnley> Okay. I stand corrected. [16:11:38 CET] <jdarnley> I guess I also had VideoLAN delete some branch I accidentally pushed to the repo. [16:12:01 CET] <jdarnley> So I guess I was Fake News [16:12:18 CET] <iive> but since the git is hosted on videlan, ffmpeg admins should ask them for any changes... so it is huge pain to mess with the repo [16:12:59 CET] <iive> there is differene between been wrong and been fake news. [16:13:16 CET] <StevenLi_> iive: do you mean , that maybe on old version control repo? [16:15:48 CET] <iive> i don't remember the details. I do remember that the commit made a huge mess, something like duplicating the history of the svn/cvs repo. [16:16:26 CET] <nevcairiel> that was long before 2014 tho [16:17:19 CET] <StevenLi_> haha, what a pitty [16:17:37 CET] <StevenLi_> haha, what a pity [16:18:34 CET] <iive> more like 2011 [17:39:07 CET] <BtbN> huh, the coverity build fails because zimg is too old [17:39:11 CET] <BtbN> it's litterally using git master [17:46:32 CET] <cone-963> ffmpeg 03Dale Curtis 07master:95bacb521af8: avcodec/vorbis: Fix another 1 << 31 > int32_t::max() with 1u. [17:51:57 CET] <jamrial> BtbN: 002db7d49a maybe [17:52:26 CET] <BtbN> yeah, but I don't understand why the build image is too old [17:52:31 CET] <BtbN> it's master from a few days ago [17:53:33 CET] <wm4> jdarnley: something wrong with that commit? [17:53:45 CET] <jdarnley> No [17:53:49 CET] <jdarnley> wghat? [17:54:00 CET] <jdarnley> Oh, the copy-pasted log from earlier? [17:54:33 CET] <jdarnley> That was just to show that one hash listed was in the git history. [17:55:05 CET] <jdarnley> Sorry about the highlight. [18:00:00 CET] <wm4> ok [18:00:43 CET] <wm4> jkqxz: what's with the intel driver and easily triggered assertions [18:03:17 CET] <omerjerk> Hi, I was looking at this bug - http://trac.ffmpeg.org/ticket/6216 [18:03:44 CET] <omerjerk> I think I'll need some spec file to tackle it. [18:03:58 CET] <omerjerk> Anyone has truehd spec? [18:06:25 CET] <durandal_1707> not here [18:07:21 CET] <omerjerk> How can I fix the bug without understanding the format? :/ [18:07:37 CET] <omerjerk> any tips? [18:07:46 CET] <jdarnley> Extreme Reverse Engineering [18:07:50 CET] <durandal_1707> omerjerk: your iq must be above 200 [18:09:30 CET] <omerjerk> didn't really understand the reverse engineering part. [18:09:32 CET] <nevcairiel> the same way the rest of the encoder was created [18:09:44 CET] <omerjerk> Neither got Paul [18:09:51 CET] <omerjerk> *Paul's sarcasm [18:10:19 CET] <nevcairiel> various methods, find a binary encoder and de-compile it, or look at what the decoder expects and try to reverse from there whats wrong [18:11:39 CET] <durandal_1707> our mlp enoder implements subset of possibilties that are allowed by decoder [18:14:52 CET] <omerjerk> Cool. got it. Will start with it. [18:59:40 CET] <jkqxz> wm4: Well, I don't feel guilty for not testing an ancient version which only works on hardware at least five generations old. [18:59:42 CET] <cone-963> ffmpeg 03Paul B Mahol 07master:e1dd97bd4c03: avfilter: add fillborders filter [19:01:01 CET] <durandal_170> how much to expect from adding simd to hflip filter? [19:10:09 CET] <wm4> why does av_get_pix_fmt_string() even exist [19:10:22 CET] <wm4> its only purpose is literally printing a formatted list of pixfmts [19:12:52 CET] <ubitux> to run ffmpeg -pixfmts iirc [19:13:01 CET] <ubitux> -pix_fmts* [19:13:05 CET] <wm4> so why doesn't ffmpeg.c implement this [19:13:12 CET] <ubitux> probably a bad reason [19:13:39 CET] <ubitux> ah it seems that's not even used [19:13:52 CET] <ubitux> 2010 [19:14:36 CET] <ubitux> which comes from avcodec_pix_fmt_string() from even earlier [19:15:16 CET] <ubitux> (2007) [19:15:37 CET] <ubitux> it's probably safe to deprecate t [19:15:39 CET] <ubitux> it* [19:42:02 CET] <SortaCore> does libx264 still use the AVCodeContext? [19:42:17 CET] <SortaCore> I have it in my code comments notes [20:02:33 CET] <jamrial> durandal_170: probably a decent boost. looks like a job for pshufb [20:03:39 CET] <durandal_170> but why it havent be added already? [20:04:11 CET] <jamrial> because nobody wrote it i suppose :p [20:20:14 CET] <durandal_170> jamrial: what if width is not multiple of 16? [20:21:46 CET] <atomnuker> pad it to the left and adjust the dst data pointer such that the last pixel lines up with the start of the frame [20:31:59 CET] <jdarnley> I love seeing users post the lame error message I put in configure [21:09:08 CET] <cone-963> ffmpeg 03Martin Vignali 07master:9bed17cd0f02: checkasm/utvideo : be more explicit to the WIDTH_PADDED define [21:31:28 CET] <JEEB> jamrial: posted the patch to fix the mediacodecdec build since you didn't :) [21:38:45 CET] <jamrial> JEEB: ah cool, thanks [21:39:03 CET] <JEEB> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221515.html [21:40:16 CET] <jkqxz> JEEB: IMO just apply that. (Though, if you care, those headers are usually in alphabetical order.) [21:41:14 CET] <jkqxz> And nice to know that lots of people are building mediacodec, I guess :/ [21:43:00 CET] <JEEB> jkqxz: I just checked in which order hevc had them and it seemed like "add to the end" more or less [21:43:06 CET] <JEEB> if it's alphabetic that's fine by me too [21:49:23 CET] <JEEB> also reported the HEVC SIMD build failure with clang + gas-preprocessor finally [21:53:02 CET] <JEEB> alright moved the header to its spot [21:56:31 CET] <cone-963> ffmpeg 03Jan Ekström 07master:6939b3cb9d60: mediacodecdec: fix build by including hwaccel.h [22:12:52 CET] <cone-963> ffmpeg 03Mark Thompson 07master:a763d278274c: examples/vaapi_encode: Fix leak on hwframe init failure [22:18:11 CET] <sfan5> michaelni: i think you're correct about ff_hevc_frame_nb_refs(), any idea where I can get the number of frames that reference the current one? [23:05:47 CET] <durandal_170> yaj, i can replace compiler now [23:11:36 CET] <atomnuker> durandal_170: what did you use? [23:12:41 CET] <cone-963> ffmpeg 03Michael Niedermayer 07master:0409d333115e: avcodec/hevcdsp_template: Fix undefined shift in put_hevc_epel_bi_w_h() [23:12:42 CET] <cone-963> ffmpeg 03Michael Niedermayer 07master:067408700453: avcodec/j2kenc: Fix out of array access in encode_cblk() [23:12:43 CET] <cone-963> ffmpeg 03Michael Niedermayer 07master:b5587fd2c6ce: avcodec/jpeg2000: Only allocate Jpeg2000Pass for the encoder [23:13:52 CET] <durandal_170> atomnuker: for remainder of mmsize i use non simd code [00:00:00 CET] --- Sat Dec 2 2017

1 0

ffmpeg.log.20171201
by burek 02 Dec '17

02 Dec '17

[00:00:57 CET] <SortaCore> play it in public and see if people give you odd looks [00:01:15 CET] <durandal_1707> TheRock: yes, first you need to teach neural networks by giving it to them [00:02:09 CET] <zash> neural networks solve all the problems! [00:03:03 CET] <alexpigment> -vf sex_video_or_nah [00:42:54 CET] <pos> An application crashes when using -vcodec copy: [00:42:55 CET] <pos> 2017-12-01 04:41:27.765298 zmc_m1 5442 WAR /srv/build/ZoneMinder2/src/zm_videostore.cpp:708: Mangled AVPacket: discarding frame zm_videostore.cpp 708 [00:42:55 CET] <pos> 2017-12-01 04:41:27.551439 zmc_m1 5442 WAR Unable to set movflags to frag_custom+dash+delay_moov [00:43:40 CET] <pos> any ideas whats up? [00:45:06 CET] <klaxa> that doesn't look like ffmpeg... zm_videostore.cpp? [00:45:23 CET] <pos> no, it's calling avconv [00:45:35 CET] <klaxa> it seems to use libav* (AVPacket) but then the call would be useufl [00:45:38 CET] <klaxa> *useful [00:45:42 CET] <klaxa> also avconv != ffmpeg [00:47:32 CET] <pos> apparently the avconv job tasked with writing the video file to disk is unable to set some flags? [00:47:54 CET] <klaxa> if it is calling avconv ask in #avconv [00:56:48 CET] <c_14> you mean #libav (I believe) [01:00:06 CET] <pos> i know this is #ffmpeg. i've run avconv -i "rtsp://source" -vcodec copy -acodec copy a.mp4 which ofc works [01:01:11 CET] <pos> avconv -i "rtsp://source" -vcodec copy -acodec copy -map 0 -movflags frag_custom+dash+delay_moov a.mp4 ofc fails [01:01:28 CET] <pos> are these extra movflags part of a separate package [01:01:45 CET] <SortaCore> see fflogger's message, pos [04:24:42 CET] <dystopia_> hello all [04:24:53 CET] <dystopia_> trying to cut 60s from an m2ts file [04:24:57 CET] <dystopia_> ffmpeg -i 00001.m2ts -t 60 -c:v copy -c:a pcm_s24le sample.m2ts [04:24:57 CET] <dystopia_> ffmpeg -i 00001.m2ts -t 60 -c copy sample.m2ts [04:25:10 CET] <dystopia_> ^both commands create an output without any audio [04:25:14 CET] <dystopia_> anyone got any ideas [04:25:53 CET] <TheRock> yes, is your windows volume maybe too small ? [04:26:42 CET] <dystopia_> there is audio in the source file TheRock which plays fine, but not in the copied sample using ffmpeg [04:26:53 CET] <dystopia_> so it's not a volume issue [04:27:28 CET] <dystopia_> no audio in the output when checking with media info/ffprobe [05:11:52 CET] <jaggz> how would I go about doing a live-preview of the output of ffmpeg, while adjusting settings (like bitrate)? [06:08:23 CET] <FunkyBob> hey all... trying to convert a video from my phone, but the frame rate is munted... it plays way too fast [06:09:05 CET] <FunkyBob> oh, looks like -r will do it [06:10:03 CET] <FunkyBob> or not :/ [06:14:42 CET] <TheRock> if you are unsure [06:14:49 CET] <TheRock> you can try all parameters from a..to z [06:17:04 CET] <FunkyBob> ... [10:19:49 CET] <Timmey> Hey guys, quick question: it seems I can't get the srt encoder to be included in ffmpeg on my raspberry pi 2 (raspbian). My ffmpeg installation on mac does have it out of the box. [10:20:14 CET] <Timmey> Anyone know if I can install it manually [12:53:52 CET] <termos> any way to set ffmpeg log level per module, like getting debug info from demuxer but not from muxers? [14:36:48 CET] <jfmcarreira> heyyy guys [14:37:45 CET] <jfmcarreira> i am using ffmpeg to demux and decode a stream, but av_read_frame returns EOF on the first call. that is quiet strange. [14:58:05 CET] <pihpah> Is it a good bitrate for a 720p video ? 764 kb/s, 23.98 fps [14:58:58 CET] <furq> depends but probably not [14:59:43 CET] <pihpah> furq: you mean such a bitrate is too great for that kind of videos? [15:00:25 CET] <pihpah> YouTube recommends on 5mbps for 30 fps videos. [15:00:41 CET] <JEEB> there is no magic bit rate [15:00:54 CET] <furq> i don't know why they'd recommend that considering they recompress 720p30 to 2.5mbit [15:00:57 CET] <JEEB> if you are using x264,5 use CRF [15:01:19 CET] <pihpah> Well, I do that with -crf 28 [15:01:44 CET] <JEEB> for x264 that's puh-ret-teh high of a value, although it's possible that it looks OK to you [15:01:55 CET] <JEEB> and if uploading to a service just encode in as high possible quality as possible if you know the service will re-encode your stuff anyways [15:02:07 CET] <furq> crf 28 will look "OK" [15:02:14 CET] <furq> it's far from archival quality though [15:07:14 CET] <pihpah> Yeah, I know that. I am using those videos for my own streaming service. Just started to think lately whether I overuse my resources by improper video encoding. [16:15:08 CET] <SortaCore> when transcoding, do you use the same hw_device_ctx for decoding and encoding? [16:15:19 CET] <SortaCore> rip buried [16:22:35 CET] <traw> what is the purpose of AVIOInterruptCB in avio_open2 function? [16:30:11 CET] <DHE> traw: some IO operations are effectively blocking, most notably network IO. this lets you provide a function that has the opportunity to veto waiting on the network and return an error code into the system [16:34:14 CET] <traw> okay thanks DHE [17:34:34 CET] <gon_> hello, came in a few days ago asking about hstack and aspect ratio. As long as the two inputs are the same height I have pretty good luck with the final output but I'm having trouble with a couple. setsar was recommended but I can't seem to use it with filter_complex https://pastebin.com/AQ3aQBsg [17:54:21 CET] <DHE> gon_: you'll have to put it all into a single -filter_compltex [18:08:43 CET] <gon_> So I'd just append that to the end of filter_complex, DHE ? Input 1 has the correct aspect ratio but for some reason input 2 is being stretched. A couple other clips I've put together have come out correctly but I just have a couple that have this issue [18:12:33 CET] <DHE> ffmpeg -i ... -i ... -filter_complex "hstack,scale=...,setsar=...[output]" -map [output] -map 0:a $CODEC_OPTIONS outputtest.mp4 [18:12:56 CET] <gon_> Thanks DHE, I'll give that a try [18:13:10 CET] <durandal_1707> gon_: if you are attempting to combine videos with different aspects you need to pad before combining [18:13:42 CET] <DHE> I made that up on the spot so it might need fixing [18:15:26 CET] <gon_> I'll look up padding since I haven't used it before. New to filters in ffmpeg [18:16:54 CET] <gon_> The heights of both inputs are the same. Some successful clips come out with the width of input1+input2 while two I've tried so far come out with input2 stretched. [19:47:41 CET] <sledg_000> ffmpeg -y -r 10 -i downloads/export_palette/001export.png -i downloads/export_palette/002export.png -i out.mp3 -filter_complex "nullsrc=size=640x480 [base]; [0:v]setpts=PTS-STARTPTS,scale=320x240[img1];[1:v]setpts=PTS-STARTPTS,scale=320x240[img2];[base][img1] overlay=shortest=1,[tmp1]; [tmp1][img2] overlay=shortest=1:x=320" -c:v libx264 -vframes 200 out.mp4 [19:48:26 CET] <sledg_000> i am trying to delay the first image [19:50:22 CET] <sledg_000> i want the first image to show for 10seconds [19:50:46 CET] <sledg_000> the second image to show after 10sec [19:52:06 CET] <sledg_000> ffmpeg -y -r 10 -i downloads/export_palette/001export.png -i downloads/export_palette/002export.png -i out.mp3 -filter_complex "nullsrc=size=640x480 [base]; [0:v]setpts=PTS-STARTPTS,scale=320x240[img1];[1:v]setpts=PTS-STARTPTS,scale=320x240[img2];[base][img1] overlay=shortest=1,XXXXXXXXXXX[tmp1]; [tmp1][img2] overlay=shortest=1:x=320" -c:v libx264 -vframes 200 out.mp4 [19:52:24 CET] <sledg_000> i feel the filter i need should where i put XXXXXXXXXXX [19:53:48 CET] <samoo8> How can I automatically rename output file like video.mkv to video-copy.mkv ? I have this bat script atm: ffmpeg -i %1 -c:v copy -c:s copy -c:a mp3 %1 [19:57:01 CET] <samoo8> i might convert mp4s also so it needs to do video.mp4 --> video-copy.mp4 also [20:25:36 CET] <dystopia_> samoo8 use an if exist before the ffmpeg command [20:28:08 CET] <dystopia_> like this [20:28:13 CET] <dystopia_> if exist video.mkv (set output=video-copy.mkv) else (set output=video.mkv) [20:28:13 CET] <dystopia_> ffmpeg -i %1 -c:v copy -c:s copy -c:a mp3 %output% [20:58:09 CET] <samoo8> dystopia_: thx mate [20:58:36 CET] <dystopia_> np [21:00:02 CET] <sledg_000> i am trying to delay the first image [21:00:03 CET] <sledg_000> <sledg_000> i want the first image to show for 10seconds [21:00:03 CET] <sledg_000> <sledg_000> the second image to show after 10sec [21:00:03 CET] <sledg_000> <sledg_000> ffmpeg -y -r 10 -i downloads/export_palette/001export.png -i downloads/export_palette/002export.png -i out.mp3 -filter_complex "nullsrc=size=640x480 [base]; [0:v]setpts=PTS-STARTPTS,scale=320x240[img1];[1:v]setpts=PTS-STARTPTS,scale=320x240[img2];[base][img1] overlay=shortest=1,XXXXXXXXXXX[tmp1]; [tmp1][img2] overlay=shortest=1:x=320" -c:v libx264 -vframes 200 out.mp4 [21:00:13 CET] <sledg_000> anyhelp [21:00:54 CET] <sledg_000> basically what i am trying to achieve is [21:01:08 CET] <sledg_000> i have img1, img2, img3 [21:01:29 CET] <sledg_000> i want to create a video to show img1 for 5 sec [21:01:45 CET] <sledg_000> then switch to img2 for 10sec [21:01:56 CET] <alexp> https://trac.ffmpeg.org/wiki/Slideshow [21:02:16 CET] <alexpigment> see the "sequential" section [21:02:22 CET] <sledg_000> yes [21:02:32 CET] <sledg_000> i used that but it does not show [21:03:00 CET] <sledg_000> i also have a background mp3 that must play at the background throughout [21:03:06 CET] <alexpigment> right [21:03:19 CET] <alexpigment> so it sounds like you want the -r to be 1/10 [21:03:33 CET] <alexpigment> and then you can define the frame rate as whatever after the -i has been specified [21:03:34 CET] <sledg_000> what happens is [21:04:11 CET] <sledg_000> the output video show img1, img2 and img3 on first frame of video [21:04:28 CET] <sledg_000> then img3 just sits all through the video [21:04:49 CET] <alexpigment> did you try -r 1/10? [21:04:50 CET] <sledg_000> i need a way to tell it to show img1 for 5 sec before switching to img2 [21:04:55 CET] <alexpigment> rather [21:05:23 CET] <alexpigment> try ffmpeg -framerate 1/10 -i [inputs] -r 24 etc [21:05:35 CET] <sledg_000> let me retry, i believe i tried every possible approach, it did not work [21:05:40 CET] <alexpigment> ok [21:05:41 CET] <sledg_000> i will retry this [21:05:55 CET] <alexpigment> i'll follow along [21:06:01 CET] <sledg_000> thanks buddy [21:08:27 CET] <alexpigment> ok, i can see what you're talking about [21:08:37 CET] <alexpigment> maybe you need to use the concat demuxer [21:23:00 CET] <alexpigment> sledg_000: https://superuser.com/questions/1049452/ffmpeg-create-a-slideshow-video-fro… [21:23:08 CET] <alexpigment> see the answer with the green check mark [21:23:20 CET] <alexpigment> as I mentioned above, you have to use the concat demuxer [21:27:07 CET] <sledg_000> thanks [21:27:28 CET] <sledg_000> i think the problem i have with the playback is from the player [21:27:50 CET] <sledg_000> vlc changes the images [21:28:18 CET] <sledg_000> but window media player just went black [21:32:18 CET] <sledg_000> thanks [21:32:32 CET] <sledg_000> seem like i am getting a way [21:33:08 CET] <JEEB> -41 [21:33:10 CET] <sledg_000> still not there but this is extremely helpful [21:35:25 CET] <alexpigment> sledg_000: when i followed that answer, i got WMP to play it correctly [21:35:44 CET] <sledg_000> now i think i need a way to access the audio length [21:35:55 CET] <alexpigment> so that it ends at the end of the track? [21:35:59 CET] <alexpigment> if so, try -shortest [21:36:27 CET] <sledg_000> do i can do an audiolength/number_of_images [21:36:37 CET] <sledg_000> to evenly distribute images [21:36:43 CET] <alexpigment> do you need to see all of the images? [21:36:47 CET] <alexpigment> or are they just kind of filler? [21:36:56 CET] <sledg_000> while ensuring the song plays through [21:37:20 CET] <sledg_000> the audio take highest priority [21:37:25 CET] <alexpigment> then use -shortest [21:37:39 CET] <alexpigment> it'll stop encoding frames at the end of the audio [21:37:46 CET] <alexpigment> put that after the inputs, btw [21:38:05 CET] <sledg_000> shortest stops at the end of the image slide [21:38:13 CET] <sledg_000> so audio never finishes [21:38:20 CET] <sledg_000> let me play around a bit [21:38:26 CET] <alexpigment> ok, so you don't have enough images then [21:38:33 CET] <alexpigment> anyway, good luck [21:38:43 CET] <sledg_000> i am guessing i need longest [21:38:48 CET] <sledg_000> if it even exists [21:39:06 CET] <sledg_000> if the audio is a 60sec audio [21:39:08 CET] <alexpigment> honestly, i've never heard of longest [21:39:15 CET] <alexpigment> it may exist, but i don't know about i [21:39:16 CET] <alexpigment> *it [21:39:32 CET] <sledg_000> then the 3 images gets splitted [21:39:38 CET] <sledg_000> thanks [21:58:36 CET] <sledg_000> -vf fps=25 option saved the day for me [22:06:22 CET] <alexpigment> sledq_000 are you in a pal country? [22:07:07 CET] <alexpigment> (i personally think pal frame rates are pointless in 2017, unless your source material is at that same frame rate) [22:07:16 CET] <alexpigment> either way, you're doing stills, so it doesn't matter really [22:08:56 CET] <furq> you know we still broadcast at 25p/50i right [22:09:26 CET] <alexpigment> furq: yep. it's just that unless your source content is 25p inherently, there's no advantage to pal frame rates [22:09:49 CET] <alexpigment> and I've yet to see a pal TV or player that isn't internally NTSC with some conversion hardware [22:10:07 CET] <alexpigment> which is why all "multi-region" blu-ray players are just PAL players [22:10:25 CET] <furq> this may be the case but it's still better than ffmpeg defaulting to 29.97 [22:10:45 CET] <alexpigment> furq: i'm not terribly concerned with the defaults [22:11:06 CET] <alexpigment> more just that it doesn't make sense to use 25fps for purely synthetic content [22:11:16 CET] <alexpigment> especially considering that it will never look smooth on a computer monitor [22:11:31 CET] <therage3> i think what alexpigment is saying that unless the origin is a PAL broadcast, 25fps doesn't make much sense [22:11:35 CET] <therage3> if i'm not mistaken [22:12:19 CET] <alexpigment> therage3: yeah, that's exactly what I was saying. maybe I jumbled some words or didn't say it eloquently enough above ;) [22:13:44 CET] <alexpigment> but yeah, i've talked to lots of pal people who are like "this pan isn't smooth". and it's because 25p or 50i just doesn't divide evenly into 60hz [22:14:32 CET] <therage3> framerates always bother me [22:14:51 CET] <alexpigment> therage3: i like the simplicity and complete ambiguity of that statement :) [22:15:52 CET] <therage3> heh [22:15:52 CET] <alexpigment> framerates bother me too, but it's usually because content providers don't care about frame rates and I have to look at judder on services that aren't worthy of paying for [22:16:07 CET] <therage3> well, if you remember yesterday, there was this NTSC DVD i was trying to detelecine [22:16:16 CET] <alexpigment> oh right [22:16:19 CET] <therage3> and it turned out the detelecine was applied in not a specified pattern [22:16:45 CET] <therage3> (the framerate comment here applies because it has to convert 29.97 to 24 after decimating duplicates) [22:17:30 CET] <alexpigment> yep [22:17:35 CET] <alexpigment> it's all kinda dumb [22:17:51 CET] <alexpigment> NTSC does the 3/2 pulldown [22:17:59 CET] <alexpigment> PAL usually does a 4% speedup [22:18:11 CET] <alexpigment> I personally prefer the former, but both are definitely compromises [22:19:24 CET] <alexpigment> what's awful though is that there are many paid tv streaming services now [22:19:46 CET] <alexpigment> DirecTV Now, Playstation Vue, YouTube TV, etc [22:20:11 CET] <alexpigment> and they take 1080i broadcasts and convert them to 720p30 or 1080p30 (and sometimes 720p60) [22:20:21 CET] <therage3> some people do notice that the speedup introduces the "chipmunk effect" into people's voices [22:20:31 CET] <therage3> and this is especially bad for musicals, where pitch perfection is required [22:21:06 CET] <alexpigment> you completely lose the 3/2 pulldown when you convert from 60i to 30p. and so judder is just awful, and unaccepatable on a paid service. but people just have very low standards and so there's not a huge uproar that forces changes to be made [22:21:34 CET] <alexpigment> yeah, the speedup is much more noticeable to me than the judder from a proper 3/2 pulldown [22:23:12 CET] <therage3> yeah [23:06:22 CET] <durandal_170> alexpigment: i pushed fillborders filter [23:08:49 CET] <alexpigment> oh nice [23:08:59 CET] <alexpigment> that'll be really handy in the future [23:09:25 CET] <alexpigment> I ended up using crop+pad yesterday, although getting the parameters right was confusing because crop and pad don't work like you'd expect [23:10:27 CET] <alexpigment> at least, crop doesn't work like you'd expect (you specify the uncropped area rather than the cropped area) [23:11:36 CET] <alexpigment> lemme rephrase: it didn't work like i'd expect, but this is because I only need to crop on one side [23:11:51 CET] <alexpigment> anyway, looking forward to using fillborders :) [23:43:11 CET] <teratorn> what's a good way to create mp4 files that use data referencing without copying frame data from a source [00:00:00 CET] --- Sat Dec 2 2017

1 0