February 2019 - Ffmpeg-devel-irc

ffmpeg-devel.log.20190222
by burek 23 Feb '19

23 Feb '19

[01:45:57 CET] <gnafu> atomnuker: I've seen that on YouTube before, too, though lately I think I've had Opus any time I've checked. [01:46:11 CET] <gnafu> (VP9+AAC) [01:52:56 CET] <atomnuker> I don't recally seeing any vp9 links without opus, maybe the player picked that combination for some reason [01:53:18 CET] <jamrial> vp9+aac sounds unusual, though, since a broswer that supports vp9 should also support opus [01:53:29 CET] <jamrial> except maybe safari [08:18:34 CET] <nevcairiel> its not like thats actually a muxed combination, thats all dash and the browser c an pick [08:48:39 CET] <kierank> atomnuker: have you been on a tour of SLAC? [09:50:08 CET] <atomnuker> slac? [10:39:23 CET] <durandal_1707> fixed one bug in bitstream parsing, more still left [11:59:47 CET] <BtbN> philipl, I'll catch up next week, not really any time at the moment. [12:29:41 CET] <atomnuker> oh, that slac? I think the train might stop through there [12:30:17 CET] <atomnuker> but even if it did, you're still in the middle of nowhere, without a car, without any taxis nearby, and mobile internet is still 5 pounds per megabyte [12:33:03 CET] <atomnuker> and I wouldn't have been fond of the prospect of walking >5km in both directions in the relative heat, I did 7km once there, I'd know [12:37:33 CET] <durandal_1707> atomnuker: i found logic error in my code, problem is how to get right *i* index in max_quant_idx[g][i] ? [12:41:44 CET] <kierank> atomnuker: not on three [12:41:56 CET] <kierank> I'd like to go one day [13:46:07 CET] <nevcairiel> durandal_1707: i got a bunch of TS satellite recordings with ac-4 [13:48:07 CET] <nevcairiel> now i just need to reach mpegts.c to understand those [13:48:11 CET] <nevcairiel> teach* [13:53:29 CET] <durandal_1707> nevcairiel: that software already have ts dshow file [13:55:10 CET] <nevcairiel> but its more fun if i can actually read it myself [14:21:02 CET] <nevcairiel> i do wonder how you are supposed to identify that its ac-4 however, it uses stream type 6 (private stream) and i dont see a registration decriptor [14:21:16 CET] <kierank> they haven't registered an identifier which is odd [14:21:48 CET] <durandal_1707> it is in some spec [14:22:37 CET] <nevcairiel> apparently there is a AC-4 descriptor that you are supposed to use [14:22:50 CET] <nevcairiel> as part of the PMT [14:23:37 CET] <kierank> still out of spec iirc [14:23:56 CET] <nevcairiel> i'm reading the DVB spec, so they just made it spec [14:24:12 CET] <kierank> I mean out of spec for mpegts (h.222) [14:24:20 CET] <kierank> iirc private stream requires a registration [14:44:48 CET] <nevcairiel> at least the ac4-descriptor is present where the spec says it should be [14:45:14 CET] <nevcairiel> but that binary decoder there still refuses to work [14:45:21 CET] <nevcairiel> so it may as wlel do a license check or s omething [14:46:17 CET] <durandal_1707> nevcairiel: can you share files? [14:46:47 CET] <nevcairiel> uploading them to my share server now [14:48:11 CET] <nevcairiel> durandal_1707: https://files.1f0.de/samples/ac4/ [14:48:41 CET] <nevcairiel> also put my hacky patch to make mpegts.c find them there [14:50:46 CET] <durandal_1707> atomnuker: in the end i made huge offset2sfb table, i do not like it [14:50:53 CET] <durandal_1707> nevcairiel: great, thanks! [14:52:38 CET] <JEEB> hmm, wonder why we don't pass on maxrate/bufsize side data by default through encoders? [14:52:46 CET] <JEEB> (for video/audio) [14:53:41 CET] <JEEB> nevcairiel: there's two things specified, I linked both specs here earlier [14:53:50 CET] <JEEB> one of them is the DVB descriptor [14:54:03 CET] <nevcairiel> i found the dvb descriptor [14:54:05 CET] <JEEB> the other is the registered thing where they literally registered id 'AC-4' [14:54:13 CET] <nevcairiel> these samples dont use that [14:54:32 CET] <nevcairiel> but they are all DVB sat broadcast [14:54:36 CET] <nevcairiel> other regions/standards may [14:54:47 CET] <JEEB> yea, I'd guess the descriptor is more used although the other thing is supposed to be a fallback [14:55:01 CET] <JEEB> "for devices that don't support the ac-4 descriptor" [14:55:08 CET] <nevcairiel> according to the DVB spec, this is the only thing they list in there [14:55:22 CET] <JEEB> yea, it's all in the back-log [14:55:26 CET] <JEEB> both docs [14:55:30 CET] <JEEB> the DVB one and the other one [14:56:17 CET] <nevcairiel> also no clue where the 0xAC comes from that TsExtractor in exoplayer uses [14:56:22 CET] <nevcairiel> probably yet another standard [15:01:58 CET] <nevcairiel> anyhow these recordings have nothing else, a language descriptor, the dvb extension descriptor which contains the ac-4 descriptor, and sometimes a second dvb extension descriptor, which i didnt bother to find out whats in it :) [15:29:03 CET] <durandal_1707> hmm, some of samples are mono with no presentations but with substreams [15:29:58 CET] <durandal_1707> all are using speech spectral frontend [15:31:59 CET] <durandal_1707> actually, i'm wrong need to look at this more [15:34:49 CET] <durandal_1707> lol, need to skip bytes, packets have signature and crc [15:36:42 CET] <nevcairiel> from TS, yeah [15:51:55 CET] <JEEB> yea, it's the sync sample thing [15:52:10 CET] <JEEB> 22:46 <@JEEB> it's like annex b I guess, except it also has frame_size() in front [15:52:13 CET] <JEEB> 22:46 <@JEEB> it then includes the raw_ac4_frame (and optionally crc_word) [15:52:16 CET] <JEEB> 22:46 <@JEEB> (crc_word when 0xAC41) [16:00:22 CET] <OmniBlade> Hello, is make fate expected to pass when building against the msvc toolset? I keep getting Use of av_clip() where av_clip_uintp2() could be used despite the code I've added not using that function. [16:00:34 CET] <OmniBlade> And indeed I get the same issue against master. [16:01:26 CET] <OmniBlade> Its just after tests/checkasm/checkasm.h if that helps. [16:01:31 CET] <nevcairiel> yes its supposed to pass [16:01:44 CET] <nevcairiel> make sure you checkout the sources using unix line-endings, or some scripts might be thrown off [16:01:59 CET] <OmniBlade> Ahh, that might have scuppered me. [16:02:16 CET] <OmniBlade> I'll change the line endings and try again. [16:04:08 CET] <OmniBlade> Thanks. [16:19:34 CET] <philipl> BtbN: no problem [16:41:51 CET] <JEEB> michaelni: I will check that specific use case when I get home. sounds like another sub2video FATE test is needed. [17:21:40 CET] <JEEB> michaelni: while i'm on the road, does it happen with the value initialized to zero as well? (that's what the struct implicitly got init to until now) [18:19:44 CET] <JEEB> nevcairiel: got back home and I had the PDF open - the 'A', 'C', '-', '4' identifier is defined in annex D of https://www.etsi.org/deliver/etsi_ts/103100_103199/10319002/01.02.01_60/ts_… [18:20:02 CET] <JEEB> basically an addition to the regd_desc list [18:20:12 CET] <JEEB> registration_descriptor AC-4 [18:20:36 CET] <JEEB> but the (preferred) way is the thing described in DVB [18:20:51 CET] <JEEB> "It is recommended that the last bytes of the descriptor are 0x41 0x43 0x2D 0x34 (AC-4) to provide a fallback signalling option for receivers that do not natively understand the respective descriptor." [18:21:53 CET] <nevcairiel> what receivers would understand ac-4 and then not implement that descriptor [18:21:54 CET] <nevcairiel> oh well [18:22:20 CET] <JEEB> indeed [19:22:09 CET] <JEEB> michaelni: ok, it works with a zero there (which is not surprising, the struct until this had been implicitly initialized to zero) [19:37:55 CET] <durandal_1707> help! can't find bug in parsing [21:08:09 CET] <cone-748> ffmpeg 03Lou Logan 07master:6f93868e464d: MAINTAINERS: remove myself as a docs & trac maintainer [21:08:33 CET] <durandal_1707> atomnuker: i guess ac-4 will need your IMDCT patch too, as there are transfer lenghts of : 2048, 1920, 1536, 1024, 960, 768, 512, 480, 384, 256, 240, 192, 128 and 96 [21:09:36 CET] <atomnuker> yeah, some are non-base-15 so mdct15 won't cut it [21:10:15 CET] <atomnuker> can the codec switch between any of them per-frame? [21:10:48 CET] <atomnuker> also what do the samples you have use? 1024/128*8 for long/transient frames? [21:11:39 CET] <atomnuker> I can't help but think they've rewritten an aac encoder to output ac4 since the terminology is similar [21:13:18 CET] <durandal_1707> one sample use 2048 for long frames, and 128, 256, 512, 1024 for transient ones, other sample uses 1536 and less values like 768, 384, 192, and 96 [21:14:47 CET] <durandal_1707> like opus it also may(almost always) resample audio internally [21:15:00 CET] <atomnuker> nice, that's kinda similar to opus [21:15:19 CET] <atomnuker> resample the audio? so does it always output at a particular samplerate? [21:15:28 CET] <durandal_1707> this is mostly to have 1:1 mapping from V to A packets [21:15:53 CET] <atomnuker> we do support switching samplerates, the only reason opus doesn't is because it can combine silk and celt which may differ in samplerates [21:16:13 CET] <durandal_1707> atomnuker: samplerate is 48000 (or 44100 and nothing else) with extensions to 96k and 192k [21:17:16 CET] <durandal_1707> atomnuker: for 2048 frame len base it give 1920 output samples for 48000 sample rate ---> to have 1:1 mapping with Video [21:17:38 CET] <durandal_1707> 1920 is just approximation, .... [21:17:59 CET] <atomnuker> wait, what? so the transform is 2048 but it cuts out 128 samples? [21:18:12 CET] <durandal_1707> atomnuker: resamples internally [21:18:33 CET] <atomnuker> ah, ok, is that signalled? e.g. output_sample_rate or something? [21:19:07 CET] <durandal_1707> yes, see resampling_ratios table in my code [21:19:55 CET] <atomnuker> ok, that's somewhat sane, on one hand we could change the samplerate of the frame and let the user deal with it or we could resample it to whatever the decoder was configured with [21:20:20 CET] <durandal_1707> it have 25 fps, 29.997 and not 30 fps :) [21:20:42 CET] <atomnuker> I'm thinking letting the user deal with variable samplerates sounds better, it should just work provided they use the PTS correctly [21:21:58 CET] <atomnuker> so there must always be 25/29.997 audio frames per second? weird, that kinda fixes encoder possibilities [21:22:33 CET] <durandal_1707> there are other options for more FPS, 100 even [21:23:12 CET] <atomnuker> eh, still weird and hard for encoders to comply with, with opus you knew you were always going to end with an integer amount of frames per second [21:23:55 CET] <atomnuker> because you have to keep track of how many frames/samples you've encoded and not change transform size bases (since they're made to match with framerates) [21:24:38 CET] <durandal_1707> i'm wrong, they have mode for 30fps and even 24fps [21:25:48 CET] <durandal_1707> yes you get exactly same number of audio frames as video frames [21:26:28 CET] <durandal_1707> internal resampling deals with of by one samples in frames [21:27:16 CET] <durandal_1707> there is special mode i think which is not limited, but only for 44100 rate [21:31:25 CET] <kierank> durandal_1707: looking forward to see how you handle 29.97 fps [21:32:02 CET] <durandal_1707> kierank: it is trivial, pick iframe and start decoding from it [21:32:11 CET] <kierank> and how many samples do you return [21:32:26 CET] <kierank> at 48khz [21:32:29 CET] <atomnuker> this sounds like it simplifies video/audio sync and locks you from using any other codecs if you don't generalize [21:32:58 CET] <durandal_1707> kierank: the amount that returns internal resampler [21:33:10 CET] <kierank> how, it's a fractional rate [21:33:32 CET] <durandal_1707> there is delay [21:34:28 CET] <kierank> you will drift unless you are careful [21:41:17 CET] <atomnuker> well, we can output more samples that the frame contains, its not like we have to respect x frames per second [21:45:34 CET] <durandal_1707> i think there is sequence counter up to 1020 just for this crap [22:53:33 CET] <gnafu> Did NDI ever get removed, per #7589? [22:53:58 CET] <gnafu> (It came up in my browser's address bar suggestions, and I was reminded of the drama.) [22:55:19 CET] <durandal_1707> gnafu: usually nothing happens here [22:55:33 CET] <gnafu> :-P [23:35:14 CET] <cone-748> ffmpeg 03Paul B Mahol 07master:c679119a73d9: avfilter/vf_amplify: add tolerance option [00:00:00 CET] --- Sat Feb 23 2019

1 0

ffmpeg.log.20190222
by burek 23 Feb '19

23 Feb '19

[00:59:24 CET] <tbrowder> hi,n [00:59:52 CET] <tbrowder> anyone active now [01:06:39 CET] <tbrowder> i'm trying to help my brother whose group just had a 50 year reunion and they took about 4 hours of video with an old camcoder that creates m2ts files. i have the ffmpeg on my debian 9 box and i have concatenated the 9 or so streams together via 'cat' to one stream of about 8 gb. i know very little about video, but one search came up with an ffmpeg execline like this: [01:09:26 CET] <tbrowder> $ ffmpeg -i in.m2ts -vcodec copy -acodec copy out.mp4 [01:10:20 CET] <relaxed> what's the problem? [01:10:26 CET] <tbrowder> does that sound like it should work? i'm about to try it but would appreciate any advice. thnx [01:10:40 CET] <tbrowder> relaxed: hi! [01:10:54 CET] <bodqhrohro> tbrowder: what are you trying to accomplish? [01:11:44 CET] <tbrowder> convert a single m2ts file to mp4 for viewing and listening via html5 on my website [01:12:08 CET] <furq> tbrowder: pastebin the output of `ffprobe in.m2ts` [01:12:28 CET] <furq> if it's h264 and aac then the command line you posted should work [01:13:17 CET] <tbrowder> ok, it will take a few minutes while i run to my big 'puter [01:14:56 CET] <tbrowder> ok, trying to paste: [01:15:09 CET] <relaxed> pastebin.com [01:19:50 CET] <tbrowder> https://pastebin.com/z1HD6eQf [01:21:02 CET] <tbrowder> i see h264 but no aac [01:24:06 CET] <tbrowder> i'm trying it anyway...something is happening... [01:32:28 CET] <furq> tbrowder: you'll need to convert the audio to aac or else it won't play back in browsers [01:32:46 CET] <furq> -i in.m2ts -c:v copy -c:a aac -b:a 192k out.mp4 [01:34:53 CET] <furq> uh [01:34:58 CET] <furq> -i in.m2ts -c:v copy -c:a aac -ac 2 -b:a 192k out.mp4 [01:36:58 CET] <tbrowder> my incantation worked like a charm! i'm not trying to edit anything, but the final product looks just like the original scene. thanks! [01:37:42 CET] <tbrowder> ah, ok, i was suckered in by the local viewer.... [01:39:58 CET] <tbrowder> furq: i'm trying your incantation... [01:40:53 CET] <tbrowder> working... [01:54:06 CET] <tbrowder> furq: thanks! bye fornow [01:54:48 CET] <Hello71> furq: won't play in *some* browsers. [01:56:00 CET] <Hello71> should work on Linux I think? I was under the impression that both firefox and chromium used ffmpeg for decoding [01:57:33 CET] <furq> firefox policy is to only support the lowest common denominator [01:57:38 CET] <furq> so stuff that should logically work on linux doesn't [01:58:18 CET] <furq> but yeah for "in browsers" read "in any browser that people might reasonably be using in 2019" [02:03:54 CET] <another> tbrowder: you might want to throw -movflags +faststart in there [02:11:13 CET] <furq> you might also want to try without -ac 2 [02:11:52 CET] <furq> i know some browsers used to have headaches with 5.1 audio, but idk if that's still true [02:11:57 CET] <furq> stereo is probably less hassle though [03:40:32 CET] <DHE> I've had android issues with 5.1 historically, but that was a year or two ago [03:44:50 CET] <furq> i can't imagine a camcorder mic is picking up quality 5.1 audio anyway [04:29:05 CET] <ossifrage> Can someone point me to an example of using libavformat to multiplex a h.26[45] elementary stream as a fmp4 stream? [13:17:32 CET] <tbrowder> furq: you're right about the mike, sound I heard is not real hugh quality, too bad [14:12:14 CET] <zaeph> Hello everyone. I'm having trouble getting ffmpeg to accept a palette for colouring sub/idx subtitles. I've extracted the palette from the .ifo file with lsdvd, but putting `-palette "286df0,&"` right before the input file doesn't change anything. [14:12:46 CET] <zaeph> Here's the command I ran: https://paste.xinu.at/eQKmxe/bash . [14:16:55 CET] <zaeph> Here's how it looks on the original DVD: https://paste.xinu.at/A0yH/ . And here's how it looks on the output file: https://paste.xinu.at/eGJ/ . Mind you, the output doesn't change whether the `palette` parameter is there or not. [14:17:59 CET] <zaeph> And I've also tried `-ifo_palette`, which didn't work either. [14:18:19 CET] <pink_mist> what if you place the parameter right after the input file? [14:18:28 CET] <zaeph> pink_mist: Let me try. [14:18:34 CET] <pink_mist> (I've no idea if that'd help or not, but it's something to try) [14:19:08 CET] <zaeph> Doesn't work either. But it was a good idea. [14:19:34 CET] <pink_mist> darn, good luck then, hope someone else can help [14:19:35 CET] <zaeph> I assumed from the wiki that it had to go before the input option: https://en.wikibooks.org/wiki/FFMPEG_An_Intermediate_Guide/subtitle_options… . [14:20:10 CET] <zaeph> Thanks. I'm not sure whether the problem comes from my file or the `palette` parameter, but I'm not well-versed in ffmpeg, so I'd rather ask here. [14:24:45 CET] <zaeph> And here's a final paste with a test file and the .ifo: https://paste.xinu.at/m-knj/ . (It also regroups all the previous pastes for convenience) [14:25:08 CET] <tinystoat> zaeph: I've just made an animated gif using a palette and this is what I had to do: ffmpeg -i "video_to_be_giffed" -i "palette_image" -filter_stuff_here "output_gif_here" [14:26:02 CET] <zaeph> tinystoat: Thank you, but this is not the same thing. I'm referring to the palette used when displaying sub/idx subtitles on a DVD. [14:26:35 CET] <tinystoat> zaeph: Ah, pity. I was hoping that would be. Good luck, wish I knew more about this myself. [14:26:55 CET] <zaeph> tinystoat: Thank you. Fingers crossed. [14:34:24 CET] <tinystoat> Same. :) [14:37:40 CET] <brejeiro[xi]> Hello. I'm recording my screen using ffmpeg, and, at some points, I'd like to create "chapters", so that I can fast forward/rewind to certain points, as I would do in DVDs. Is it possible? [14:43:41 CET] <DHE> depends on the file format. mkv can do that, mp4 can't I believe [14:49:01 CET] <brejeiro[xi]> DHE: hmmm, I would have to use mp4. But I guess I might think of another way to do this. How would I do that in MKV? [14:50:36 CET] <DHE> if your'e doing it live, you probably can't do it in ffmpeg in one shot. [14:52:05 CET] <DHE> hmm... I'm actually not sure. the docs specify a chapter file but aren't clear on the formatting [14:52:18 CET] <DHE> maybe you just want to use an external tool to add them once you have your timestamps [14:54:29 CET] <brejeiro[xi]> I don't want to use an external tool to do that. Can you point me to the docs you referred to? [14:55:04 CET] <brejeiro[xi]> The thing is the video is getting recorded on a limited HW, so every byte matters! [14:55:14 CET] <DHE> when in doubt, https://ffmpeg.org/ffmpeg-all.html literally has everything. just takes a while to load. :) [14:57:49 CET] <brejeiro[xi]> Hell yeah! That rocks! Thank you very much, it sure will be very useful!! [21:25:06 CET] <zaeph> Hello everyone. Im having trouble getting ffmpeg to accept a palette for colouring sub/idx subtitles. Ive extracted the palette from the .ifo file with lsdvd, but putting `-palette "286df0,&"` right before the input file doesnt change anything. You can find more info here: https://paste.xinu.at/m-wlNiJ/ [21:25:31 CET] <zaeph> (This is a copy-paste from an earlier message sent here. Just trying one last time, and then I'm giving up.) [21:26:04 CET] <JEEB> don't worry, people often are AFK. just stay around and most likely someone will respond (like I just did) [21:26:36 CET] <JEEB> ok, so the dvdsub decoder has an AVOption called like that [21:26:36 CET] <JEEB> libavcodec/dvdsubdec.c: { "palette", "set the global palette", OFFSET(palette_str), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, SD }, [21:27:01 CET] <JEEB> and you have defined the palette before input, which is correct for decoder options [21:28:36 CET] <zaeph> JEEB: Thanks for answering. I've browsed the manual and the web extensively looking for details on the topic, but there was very little to see aside from an exchange on the mailing list. [21:30:01 CET] <JEEB> the parse_palette function is pretty simple [21:30:22 CET] <zaeph> The only thing that brought the beginning of a result was putting the subtitle tracks alone in a .mkv container, and then mux them together with mkvtoolnix, but that's because mkvtoolnix threw an error saying that it couldn't find the .IFO style and used its own default. [21:31:36 CET] <zaeph> I don't know how ffmpeg works, but judging from what what I've tested, this seems to be a problem with that parameter. I wish I could test it out with another file and palette, but I don't have access to any of those right now. [21:31:46 CET] <c_14> Have you tried using -ifo_palette instead? I have (at some point long, long ago) had that work for me [21:32:08 CET] <zaeph> c_14: I did try it before the input, and it didn't change anything. [21:32:13 CET] <c_14> meh [21:32:16 CET] <zaeph> I didn't try to put *after* the input, though. [21:32:30 CET] <JEEB> after input is encoding params [21:32:38 CET] <JEEB> http://up-cat.net/p/5fbeaf6f [21:32:46 CET] <JEEB> you could test with this [21:32:51 CET] <JEEB> that should log what the function parsed [21:32:57 CET] <zaeph> I also tried to see if the the verbose debug had anything to say, like if it couldn't find the .IFO or something, but nothing appeared there. [21:33:02 CET] <JEEB> also [21:33:08 CET] <JEEB> I just noticed you did -c:s copy [21:33:13 CET] <JEEB> that's not going to decode anything [21:33:26 CET] <JEEB> and thus that makes sense why that palette never got applied :P [21:33:32 CET] <JEEB> since you were just copying the stream through [21:34:03 CET] <furq> i mean that sort of makes sense except the palette isn't part of the stream [21:34:15 CET] <furq> otherwise you wouldn't need to specify it manually [21:34:33 CET] <JEEB> well the palette/ifo_palette parameters are for the decoder [21:34:39 CET] <zaeph> JEEB, furq: That's what I thought, and I've tried experimenting with that. I'd agree with furq that it doesn't qualify as the subtitle stream per se, but at the same time, I see your point. [21:34:44 CET] <furq> yeah i'm sure that's the actual problem [21:34:56 CET] <furq> i'm just saying it doesn't necessarily make sense from a ui perspective [21:35:03 CET] <JEEB> yes, that I agree with [21:35:16 CET] <JEEB> I'm just looking at how it works and noticed the copy codec [21:35:25 CET] <JEEB> thus not surprising that the option didn't get applied [21:35:36 CET] <JEEB> (since it's an option of a *decoder*) [21:35:40 CET] <furq> right [21:35:58 CET] <zaeph> What should I use then instead of copying the stream? Reencode it to a different format that supports vobsub? [21:36:17 CET] <furq> there is a dvdsub encoder so i guess try that [21:36:30 CET] <JEEB> -c:s dvdsub, yup [21:36:48 CET] <zaeph> Something like that? -codec:s dvdsub -f vob [21:36:56 CET] <JEEB> no need for -f vob [21:37:00 CET] <JEEB> since you need matroska, no? [21:37:11 CET] <furq> dvdsub should mux into matroska [21:37:13 CET] <zaeph> Oh, yeah, sorry, thought that was the format for the sub itself. [21:37:26 CET] <JEEB> of course the best solution would be to somehow insert the palette into extradata or wherever it is in lavf land [21:37:35 CET] <JEEB> and do no re-encoding of subtitles [21:37:36 CET] <zaeph> Splendid, I'll give it a shot. I might have deleted the concat vob in a fit of desperation earlier today, so give me a minute to concat it back. [21:37:59 CET] <zaeph> Would there be a convenient way to do that with a mkv? [21:39:49 CET] <furq> if you mean concat a dvd title into an mkv then makemkv will do it [21:40:04 CET] <zaeph> Oh no, I was talking about JEEB's point about the extradata. [21:40:04 CET] <furq> i normally use tccat | ffmpeg [21:40:09 CET] <furq> oh right [21:40:20 CET] <zaeph> Sorry, should have mentioned his/her name. [21:40:34 CET] <furq> well yeah i noticed you're seeking into the vob, so i figured you probably just concatenated every vob and you're then seeking to the title start [21:40:46 CET] <furq> ideally you should do it in a way that actually parses the titlesets properly [21:41:13 CET] <furq> a bunch of distros dropped tccat though which is annoying [21:41:45 CET] <zaeph> furq: I'm going to be honest with you, it's my first time doing this. The only experience I have ripping a DVD resulted in me having a chapter-less, subtitle-less file which was interlaced, so well, can't say it went too well. [21:42:02 CET] <furq> yeah working with dvds is generally annoying [21:42:12 CET] <zaeph> Arch seems to have it in transcode, so it seems that I'm in luck. [21:42:37 CET] <furq> makemkv might be better if you don't mind using a gui tool [21:42:41 CET] <furq> it'll actually keep the chapters [21:43:26 CET] <zaeph> So, it will just concat everything together, and I can run ffmpeg after to deinterlace the resulting file? [21:43:50 CET] <furq> yeah [21:44:18 CET] <zaeph> All right. I'll try that and report back when it's done. [21:44:36 CET] <zaeph> I'll still try with the basic concat first to see if I can it to work without copying the subtitle stream, just for legacy. [21:44:41 CET] <furq> you can pipe tccat straight to ffmpeg, with makemkv you need to go through a temp file [21:45:14 CET] <zaeph> tccat won't keep the chapters, that's the only difference you've mentioned, right? [21:46:10 CET] <furq> there are probably others, it's been a while [21:46:46 CET] <zaeph> Right. Well, it's not something that I'm planning to do often anyway. [21:48:41 CET] <MotionVector> Hello All, quick question. I encoded a video stream with mpeg4 codec on macbook using avfoundation (via the camera). It didn't really encode at the frame rate that I specified in the cmd line. No matter. Is there a field where this encoded frame rate is kept as part of the headers? Or is the only way for me to determine this is to count number of VOP frames within a given time increment? TIA! Don't want to use ffprobe (I [21:49:30 CET] <MotionVector> If I should ask this question in the dev channel, I will ask there. Thought I'd start here [21:49:42 CET] <JEEB> did you output into a container? [21:50:12 CET] <JEEB> the container might have the PTS from the avdevice [21:50:28 CET] <JEEB> granted if your input avfoundation device provides that [21:51:05 CET] <MotionVector> ./ffmpeg -f avfoundation -framerate 29.97 -video_size 640x480 -i "0" -c:v mpeg4 -b:v 800k -g 1 test3_i_30_qvga.mp4 [21:51:17 CET] <JEEB> if you are using ffmpeg.c (the command line API client), then -debug_ts will show you the timestamps received from lavf/lavd [21:51:22 CET] <JEEB> ok, you are using ffmpeg.c [21:51:23 CET] <MotionVector> that's the cmd line I used to encode, not sure how to specify a container [21:51:34 CET] <JEEB> it got guessed from the extension [21:51:38 CET] <JEEB> thus it's mp4 [21:51:45 CET] <JEEB> so in theory the PTS should be set [21:52:54 CET] <MotionVector> the mp4 header itself doesn't give me much info.. it has 3 atoms or something like that (one that is a container 'mdat' I think) [21:53:18 CET] <JEEB> L-SMASH's boxdumper can give you the timestamps coded in the mp4 [21:53:24 CET] <MotionVector> and the actual video starts off with a 00 00 01 B3 (a GOV header) [21:54:14 CET] <JEEB> boxdumper --timestamp file.mp4 > timestamps.txt [21:54:26 CET] <MotionVector> ffprobe does give me the net framerate [21:54:35 CET] <JEEB> although I would recommend checking out the output of -debug_ts [21:54:38 CET] <JEEB> when encoding [21:55:00 CET] <JEEB> (you might want to redirect the stderr into a log file a la " 2> encode.log") [21:55:16 CET] <JEEB> since it will log the timestamps received and converted and passed throughout ffmpeg.c [21:55:37 CET] <MotionVector> will give the boxdumper a shot. and yes, I agree with your debug_ts comment :) .. this was my first encode using ffmpeg [21:55:40 CET] <JEEB> if the input has timestamps, it should show them being passed through into the output [21:56:37 CET] <MotionVector> I do see the timestamps in each frame header (VOP header) [21:56:49 CET] <MotionVector> well, relative timestamps anyway [21:57:04 CET] <MotionVector> starting at 00:00:00 and offsets [21:57:14 CET] <JEEB> well I'm expecting you to complain because the mp4 timestamps seem weird :P [21:57:18 CET] <MotionVector> (in the byte stream I meant) [21:57:21 CET] <JEEB> as in, the container ones [21:57:35 CET] <JEEB> thus I recommended l-smash's boxdumper and -debug_ts in ffmpeg.c [21:57:37 CET] <MotionVector> no actual encoded bitstream [21:57:40 CET] <JEEB> yes I know [22:15:07 CET] <zaeph> JEEB, furq: Guys, you were absolutely right about the `-c:s copy`, that was the problem. Thank you for your wonderful help. :) [22:15:42 CET] <JEEB> -c:s copy basically says, "for selected subtitle streams, copy the AVPackets without going through a decoder" [22:16:18 CET] <JEEB> or instead of copying, just "pass the AVPackets without going through a decoder and an encoder" [22:16:29 CET] <zaeph> Yeah, but I think I was confused by the fact that the palette info was in a remote file, which made it seem like the subtitles themselves didn't have to be reencoded. [22:17:06 CET] <JEEB> well in theory if someone writes a bit stream filter or an option to either the demuxer or muxer [22:17:21 CET] <JEEB> you could replace the palette [22:17:30 CET] <JEEB> hint: nobody has done that [22:17:46 CET] <zaeph> Right, I get it. Still, I'm not getting quality loss, so I think I'm good to go. [22:18:04 CET] <zaeph> If there's a loss in quality, it's still much milder than having yellow subtitles. [22:18:43 CET] <JEEB> for a long time we didn't have similar header changing video packet filtering in FFmpeg, but nowadays we have. so it's not unheard of that such runtime filtering/editing features get implemented [22:20:12 CET] <zaeph> I'll be on the lookout the next time I get a DVD to rip, then. [22:22:07 CET] <zaeph> The last thing I need to figure out is how to get the chapters. [22:22:22 CET] <zaeph> It's a much more trivial issue than the subtitles, though, but I still wonder if I can do it. [22:22:37 CET] <JEEB> they're in the playlists and I don't think FFmpeg has support for those [22:22:52 CET] <JEEB> there's probably plenty of things that would extract those [22:22:57 CET] <furq> it's not something you can do with just ffmpeg [22:23:08 CET] <zaeph> Apparently mplayer can do that. Mux with mkvtoolnix after? [22:23:09 CET] <furq> mkvtoolnix has support for chapter files and there are tools that will extract them from an ifo in the right format [22:23:17 CET] <furq> but i can't think of one for linux off the top of my head [22:23:39 CET] <JEEB> one could write a tool based on the dvdnav/whatever libraries [22:23:55 CET] <JEEB> which are cross-platform [22:52:50 CET] <zaeph> I'm trying something out with ogmrip. [22:53:35 CET] <zaeph> Well, apparently it just uses mencoder as its backend for getting the chapters, so I'll try that instead. [23:33:35 CET] <zaeph> All right, I've given up on the automatic retrieval. mkvtoolnix can take an .xml file with the chapters listed in it, so I'll just go that route since it's only one DVD. [23:33:49 CET] <zaeph> Thanks again for your help figuring everything out. [00:00:00 CET] --- Sat Feb 23 2019

1 0

ffmpeg-devel.log.20190221
by burek 22 Feb '19

22 Feb '19

[04:45:05 CET] <philipl> BtbN: https://github.com/philipl/nv-codec-headers/commit/2382e15b6e2e70ff5e4ff10b… [12:27:56 CET] <JEEB> there, one patch posted [12:28:34 CET] <JEEB> (was looking for the simplest way yesterday to fix that issue, and finally finished testing) [12:44:08 CET] <JEEB> well that was one quick LGTM [14:23:34 CET] <nevcairiel> sometimes fixes are hard to find but easy to verify [15:02:36 CET] <JEEB> true [15:02:51 CET] <JEEB> esp. when a 30MiB sample caused almost 800MiB of RAM usage 8) [19:20:24 CET] <cone-262> ffmpeg 03Jan Ekström 07master:8cf757ee8d80: ffmpeg_filter: initialize sub2video.end_pts together with last_pts [19:29:21 CET] <durandal_1707> how many GBs i need to install MSVC 2017? [19:29:55 CET] <JEEB> about 8? you can actually pick the components nowadays but the IDE is required [19:30:29 CET] <j-b> a bit more, no? [19:36:57 CET] <durandal_1707> this crap needs >60GB [19:45:05 CET] <nevcairiel> VS itself is only like 4gb, plus some shared stuff and the windows sdk, overall you should probably stay below 10 i would reckon [19:45:48 CET] <nevcairiel> if you only install the C/C++ target anyway [19:48:14 CET] <nevcairiel> at least with 2017, which has that nice flexible installer (finally, before that the installer was terrible) [19:48:54 CET] <JEEB> yea [19:49:01 CET] <JEEB> as I said, you can pick the components these days [19:49:20 CET] <durandal_1707> right now it is downloading 1.6 GB [19:58:14 CET] <nevcairiel> technically you could save space by only getting the compiler and sdk, and foregoing the IDE [19:58:33 CET] <nevcairiel> but i dont think they have a finished "package" for that, and you would have to pick the right components manually [20:39:26 CET] <durandal_1707> michaelni: fix your fuzzing timeouts [21:23:05 CET] <durandal_1707> do i need to install git to fetch lavfilters code? [21:23:44 CET] <JEEB> that's the simplest I'd say [21:23:52 CET] <nevcairiel> why do you want to build it anyway [21:23:56 CET] <JEEB> http://git.1f0.de/gitweb?p=lavfsplitter.git;a=summary;js=1 [21:24:05 CET] <JEEB> nevcairiel: he wants to add AC-4 so he can feed it to the DShow decoder [21:24:15 CET] <JEEB> and compare to his decoder [21:24:39 CET] <nevcairiel> there is a dshwo decoder? [21:24:53 CET] <JEEB> unless the ax file is vfw, yes [21:25:02 CET] <nevcairiel> i can probably add demuxing support in a few minutes and make a binary [21:25:08 CET] <nevcairiel> if there is a demuxing patch somewhere [21:25:15 CET] <JEEB> also what the DShow UUID is [21:25:19 CET] <JEEB> that part I didn't know :P [21:25:29 CET] <durandal_1707> it is dshow, but it may be locked [21:25:29 CET] <nevcairiel> well the decoder would usually tell you [21:25:41 CET] <nevcairiel> where can i find it? [21:26:54 CET] <durandal_1707> 0x7E326AC2, 0x0A60, 0x402C, 0xBB, 0xBC, 0xC1, 0xCD, 0x90, 0xC7, 0x66, 0x93, (for mplayer), dshow decoder is part of StreamXpert 2something [21:28:00 CET] <JEEB> right, dektek [21:28:07 CET] <JEEB> *dektec [21:29:39 CET] <durandal_1707> also it probably does not decode 2 version of bitstreams [21:29:44 CET] <nevcairiel> it even c omes with ffmpeg l ibraries =p [21:30:05 CET] <durandal_1707> yea, old libav actually [21:30:53 CET] <durandal_1707> i havent checked if libs are modified somehow.... [21:33:24 CET] <nevcairiel> the filter exposes a "AC4 " media type, so that seems promising [21:33:49 CET] <nevcairiel> next question, where can i find a sample that might work? :) [21:35:13 CET] <nevcairiel> i got the mp4 ac-4 patch from the ml [21:35:47 CET] <durandal_1707> http://dash.akamaized.net/dash264/TestCasesMCA/dolby/5/1/Living_Room_720p_2… [21:36:41 CET] <JEEB> yea, DASH-IF's sample collection is the only place I ever saw public AC-4 samples at [21:36:57 CET] <JEEB> other than that one raw bit stream @ Dolby's Exoplayer fork [21:38:28 CET] <nevcairiel> lets see if this decoder works [21:40:06 CET] <JEEB> the decoder is expecting MPEG-TS so I wonder if MP4 and MPEG-TS use the same packet format [21:40:20 CET] <nevcairiel> hrm it connects but doesnt decode anything [21:40:23 CET] <JEEB> IIRC there was some AC-4 packet format defined [21:40:51 CET] <JEEB> > raw_ac4_frame, as defined in ETSI TS 103 190-1 [1], clause 4.2.1 [21:44:23 CET] <JEEB> also MPEG-TS might be utilizing the ac4_syncframe() structure [21:44:26 CET] <JEEB> https://www.etsi.org/deliver/etsi_ts/103100_103199/10319001/01.03.01_60/ts_… [21:44:26 CET] <nevcairiel> rebuilding with the raw ac4 reader and seeing if it likes the exoplayer sample [21:44:51 CET] <JEEB> yea, raw AC-4 should be ac4_syncframe() based [21:44:59 CET] <JEEB> 0xAC40 / 41 [21:45:19 CET] <nevcairiel> hate codecs with multiple bitstream variants [21:45:33 CET] <nevcairiel> stop saving one byte per frame [21:46:03 CET] <JEEB> it's like annex b I guess, except it also has frame_size() in front [21:46:21 CET] <JEEB> it then includes the raw_ac4_frame (and optionally crc_word) [21:46:30 CET] <JEEB> (crc_word when 0xAC41) [21:46:48 CET] <nevcairiel> i smell bsfs in the future [21:47:10 CET] <JEEB> at least the raw ac4 frame structure should be the same but I wonder what the dshow decoder wants (extracted or within that syncframe structure) [21:47:24 CET] <nevcairiel> well the data out of the mp4 frame didnt work [21:47:36 CET] <JEEB> yea, those samples should be just raw_ac4_frames [21:47:46 CET] <JEEB> since the AC-4 in ISOBMFF spec seems to define it as such [21:47:57 CET] <JEEB> then it... probably wants ac4_syncframes XD [21:48:49 CET] <JEEB> also wow [21:48:51 CET] <JEEB> 16bit frame_size [21:49:05 CET] <JEEB> then if frame_size == 0xffff => additionaly 24 bits of frame_size [21:49:47 CET] <nevcairiel> still not doign any decoding this thing [21:50:32 CET] <JEEB> do you see the 0xAC4{0,1} sync words if you dump the packets' first X bytes? [21:50:59 CET] <JEEB> (also I just noticed the sync word has "AC4" in it [21:52:49 CET] <nevcairiel> its lacking a parser, so the frames from the raw file are probably just jumbled up [21:52:58 CET] <JEEB> quite possible [21:53:05 CET] <durandal_1707> it may expect whatever as it is for stream analytics [21:54:39 CET] <durandal_1707> the mp4 files have only raw ac4 [21:55:06 CET] <nevcairiel> a ts file might be useful, but if those dont exist [21:55:23 CET] <durandal_1707> also it might only working with proper license [21:55:39 CET] <nevcairiel> perhaps [21:56:29 CET] <cone-262> ffmpeg 03Marton Balint 07master:5adc4a98b362: avformat/mpegtsenc: add support for service and provider names with utf8 encoding [21:56:30 CET] <cone-262> ffmpeg 03Marton Balint 07master:a899b3b3c5f5: doc/formats: add reference to ffmpeg(1) stream specifiers as that docs is more complete [21:57:59 CET] <durandal_1707> also looks like here nobody have capture card :( [22:01:57 CET] <atomnuker> even if they did is ac4 being broadcast right now? [22:02:08 CET] <atomnuker> and even if they did it would likely be in north america only [22:04:41 CET] <JEEB> atomnuker: I hear eastern paris has some [22:07:22 CET] <atomnuker> pirate broadcast? [22:08:04 CET] <atomnuker> or some sort of inverse border blaster from the us operating at XX megawatts? [22:13:55 CET] <JEEB> > NRJ conducted broadcast tests for UHD 4K, HDR and Dolby AC-4 over DTTV in Paris and other regions across France (as well as by satellite) on three DTTV channels over two weeks. The first service was in UHD 4K HDR HLG 50p (over 24 Mbps high-speed broadband), the second and third in HD+ 1080p50 HDR HLG at different, lower rates. [22:25:31 CET] <nevcairiel> i havent even seen a real-world hlg sample [22:25:38 CET] <nevcairiel> .. not that I have looked [22:25:43 CET] <nevcairiel> but users also didnt complain yet [22:25:49 CET] <JEEB> travelxp .ts [22:26:22 CET] <nevcairiel> the nice thing about HLG is that you might just be watching it as SDR and never be the wiser =p [22:26:34 CET] <JEEB> well it still has the BT.2020 usually [22:26:52 CET] <JEEB> BT.709 + HLG is possible, but less likely [22:27:46 CET] <durandal_1707> https://www.dvbviewer.tv/forum/topic/62027-dolby-ac4-sound-track/ ---> ask him for capture? [22:28:44 CET] <nevcairiel> i know some of the devs, they use my filters afterall, I can inquire [22:30:53 CET] <nevcairiel> sent him a mail [22:31:12 CET] <nevcairiel> (its the griga person talking with the user in that thread) [22:32:10 CET] <durandal_1707> maybe ac4 is no longer broadcast at all, it was just for testing... [22:32:26 CET] <j-b> you wish [22:32:58 CET] <JEEB> what j-b says... [22:33:01 CET] <JEEB> once they blowjob in... [22:33:25 CET] <durandal_1707> codec is too much descriptive and bloated [22:33:30 CET] <JEEB> they definitely have a better track record at getting into this stuff than DTS [22:33:43 CET] <nevcairiel> wasnt ac-4 supposed to be a mainstream object-based codec, or am i misremembering stuff again [22:33:45 CET] <JEEB> also this is what dolby's ES parser does > https://github.com/DolbyLaboratories/dlb_mp4base/blob/master/src/esparser/p… [22:33:57 CET] <JEEB> nevcairiel: marketing wankery says that, and I think in theory they have that [22:33:59 CET] <durandal_1707> nevcairiel: yes, 2 bitstream version have object crap [22:34:42 CET] <nevcairiel> anyhow i'll let you know if i hear anything from the dvb viewer people [22:34:48 CET] <JEEB> cool [22:36:17 CET] <JEEB> another thing was the MPEG-H audio thing [22:36:23 CET] <JEEB> which doesn't seem to have gone anywhere? [22:36:41 CET] <JEEB> although I've seen broadcast things at least theoretically having support for it [22:37:16 CET] <nevcairiel> it seems non-mainstream at best [22:37:20 CET] <nevcairiel> with its 128 audio channel shit [22:37:28 CET] <JEEB> yea [22:38:14 CET] <nevcairiel> aac still seems to be good enough for the web, and mpeg-audio hasnt been in broadcast since mp2 [22:39:51 CET] <nevcairiel> compression-wise, audio probably doesnt have that many low-hanging fruit anymore [22:40:03 CET] <nevcairiel> so they try to kill it with fancy features that noone wants [22:40:14 CET] <JEEB> yuppo [22:40:55 CET] <nevcairiel> ac3 is relatively old, so ac4 probably has some reason to exist, but aac is doing fine, so .. [22:41:19 CET] <JEEB> yea, I'd either AAC or Opus if I was doing broadcast :P [22:41:34 CET] <durandal_1707> what about he++ aac or whatever it is called? [22:41:43 CET] <JEEB> isn't that low low bit rate? [22:41:45 CET] <nevcairiel> there is so many of those now [22:41:50 CET] <j-b> HE-AAC-v2-ELD [22:41:51 CET] <nevcairiel> and yeah they mostly just focus on even lower bitrates [22:42:05 CET] <nevcairiel> at "normal" bitrate (ie 96k+) all these extensions do nothing [22:42:43 CET] <nevcairiel> there is also xHE-AAC now, which apparently android started to support recently [22:42:55 CET] <JEEB> through fdk-aac yea [22:43:09 CET] <nevcairiel> stealing ideas from opus, splitting music and speech [22:44:08 CET] <nevcairiel> but all of those aim at really low bitrates, so yeah [22:50:01 CET] <atomnuker> speaking of aac, I saw a tweet peloverde did a few days ago showing a vp9 facebook video with aac audio [22:50:34 CET] <atomnuker> thought it was weird not to see opus used [23:38:13 CET] <kurosu_> Dolby has an annex in France, and funny enough, not in Paris, in the French Riviera, rather [00:00:00 CET] --- Fri Feb 22 2019

1 0

ffmpeg.log.20190221
by burek 22 Feb '19

22 Feb '19

[02:04:33 CET] <faLUCE> Hello, does av_write_trailer() return immediately (at least for MPEGTS and MATROSKA) or does it have to calculate indexes? [02:05:34 CET] <faLUCE> (I mean: if the recorded file is big, does av_write_trailer() require some time in order to finalize? [02:05:37 CET] <faLUCE> ) [02:18:54 CET] <DHE> mpegts doesn't have an index and usually finishes immediately. other file formats will vary [02:20:57 CET] <faLUCE> DHE: what about matroxa ? [02:21:08 CET] <faLUCE> matroska [02:25:07 CET] <DHE> can't answer what I don't know [02:25:16 CET] <faLUCE> ok [04:23:03 CET] <kepstin> matroska does have to write out an index at the end, yeah [04:23:24 CET] <kepstin> should be pretty quick, since i think it builds the index as it goes, it's just a write out at the end. [04:24:11 CET] <kepstin> the slowest format is mp4 with "-movflags faststart", which rewrites the entire file when closing it. [04:56:09 CET] <Hello71> what happens if you do -moov_size -movflags faststart [05:19:31 CET] <kepstin> i'm actually not sure what hapens when both options are used. with just moov_size it reserves some space at the start of the file, and if the moov fits there it will seek back and write it at the start instead of the end. [12:11:36 CET] <ossifrage> Any ideas how to get the minimal latency out of ffplay when playing an h.264 elementary stream [12:12:18 CET] <ossifrage> This: .... | ffplay -f h264 -probesize 32 -sync ext -flags low_delay -framedrop - seems to accumulate latency [13:27:34 CET] <faLUCE> kepstin: thanks. I use a single thread, then I have to write the trailer quickly [14:29:26 CET] <fling> Is it a bad idea to use ffmpeg on numa hardware? [14:29:53 CET] <fling> I'm getting really bad artifacts when capturing h264 from a v4l device on kgpe-d16. [14:30:03 CET] <fling> Can't I fix this easily? Should I run ffmpeg in qemu instead? [14:33:30 CET] <iive> fling, ffmpeg is mostly single threaded, with some codecs and filters using more threads [14:34:21 CET] <iive> it is not very plausible that the numa would be causing problems. [14:34:55 CET] <DHE> how is ffmpeg in qemu going to perform BETTER than bare metal? [14:36:00 CET] Last message repeated 1 time(s). [14:36:05 CET] <DHE> running ffmpeg on a single numa node may increase performance a bit. numactl can help here. but I'm not expecting it to be the difference between life and death [14:36:40 CET] <fling> DHE: I'm reading this -> https://www.coreboot.org/Board:asus/kgpe-d16#MCM.2FNUMA_notes_-_Read_if_you… [14:36:45 CET] <fling> DHE: >> The correct way to do this is to create a VM with properly pinned CPU's including iothread/emulator with all of the RAM on one node which is the same one that your interrupts for assigned devices such as graphics usb etc are being processed on. [14:36:58 CET] <fling> Looks like there is some numa magic& [14:38:04 CET] <DHE> numactl --hardware # and view the topology [14:38:16 CET] <iive> it talks about speed [14:38:41 CET] <iive> getting corruption means you are having major flaw. [14:38:43 CET] <DHE> which COULD be a problem for realtime encoding, but usually that's pretty easy to spot in ffmpeg [14:39:00 CET] <iive> fling, what encoder are you using? [14:39:46 CET] <DHE> PS1="(node0)$PS1" numactl --physcpubind=0 --preferred=0 $SHELL [14:39:55 CET] <fling> iive: ffplay -f v4l2 -input_format h264 -video_size 1920x1080 -framerate 30 -i /dev/video0 [14:40:05 CET] <DHE> or something like that to get a node-0 shell. note that exceeding the memory capacity of node-0 will spill into node 1, etc [14:41:18 CET] <iive> fling, so you not using any encoder, you get the h264 stream from the device? [14:41:32 CET] <iive> does it play correctly if you store it as file first? [14:43:21 CET] <fling> DHE: https://paste.pound-python.org/show/c7z5P9bXGVBCimPn2Ad0/ [14:43:36 CET] <fling> iive: yes, will try to put it in a file& [14:44:15 CET] <DHE> Ohhh... 4 nodes... [14:44:43 CET] <DHE> only 8 cores/threads? is this a threadripper 1950x? [14:45:34 CET] <fling> DHE: kgpe-d16 :D [14:46:38 CET] <fling> iive: saving to a file now and watching it with mpv [14:46:55 CET] <fling> iive: it is sometimes needed to wait for a minute or two for the artifacts to appear [14:48:00 CET] <DHE> costs aren't as bad as I thought they'd be. my dual xeons are usually 11 and 21, you have to 10 and 16 [14:49:35 CET] <fling> this does not help btw -> `numactl --physcpubind=0 --preferred=0` [14:50:00 CET] <fling> iive: I see no artifacts playing from the file for some reason [14:50:20 CET] <fling> iive: is it a bug in ffplay? [14:50:53 CET] <iive> donno, try playing the file with ffplay [14:51:30 CET] <fling> I will start new recording and will put ffplay and mpv in parallel [14:51:36 CET] <fling> I think it is just luck :P [14:53:37 CET] <iive> is it cable/tv capture or hardware encoder on camera on analog input? [14:53:53 CET] <iive> the thing you get the stream from? [14:54:27 CET] <fling> iive: c920 camera [14:56:27 CET] <fling> Ok, looks like I can't reproduce with a file. [14:56:37 CET] <fling> Will try a pipe now :P [14:58:31 CET] <fling> iive: reproduced piping to ffplay [15:01:02 CET] <fling> Can't reproduce with mpv reading from pipe. [15:02:25 CET] <fling> Ok, visible with mpv too but less severe for some reason. [15:02:40 CET] <fling> So should be numa related then as happens only on this box. [15:02:50 CET] <fling> DHE: costs? [15:04:31 CET] <amosbird> hi [15:04:34 CET] <DHE> fling: the values in that 4x4 table [15:04:44 CET] <amosbird> I'm trying to use ffmpeg to build a delayed screenshotter [15:04:45 CET] <amosbird> ffmpeg -f x11grab -show_region 1 -s "$W"x"$H" -i $ffmpeg_display+$X,$Y -framerate 1 -vframes 1 -f singlejpeg - | xclip -selection clipboard -t image/jpeg [15:05:13 CET] <amosbird> how can I make ffmpeg hold the region for given seconds and only takes the last frame as the singlejpeg output? [15:05:44 CET] <amosbird> can I also make sure it doesn't consume any cpu cycles in the delay period? [15:06:36 CET] <fling> amosbird: use -ss "$delay_seconds" before -i [15:07:09 CET] <amosbird> fling: thanks [15:07:20 CET] <amosbird> does that work as I expected? [15:07:25 CET] <fling> amosbird: or sleep $delay_seconds ; ffmpeg& [15:07:29 CET] <fling> amosbird: I don't know. [15:07:32 CET] <amosbird> sleep won't work [15:07:37 CET] <amosbird> as it doesn't hold the region [15:07:44 CET] <amosbird> or else I don't need ffmpeg [15:07:59 CET] <fling> I don't understand the hold thing [15:08:30 CET] <amosbird> yeah, it works as expected [15:08:32 CET] <amosbird> thank you fling [15:08:44 CET] <fling> amosbird: yw! what is hold for anyway? [15:08:56 CET] <amosbird> holding the area boarder [15:09:04 CET] <amosbird> -show_region 1 [15:09:19 CET] <amosbird> more like showing [15:09:22 CET] <fling> I need to try this myself& [15:09:44 CET] <amosbird> it consumes 0.23 cpu [15:09:50 CET] <amosbird> acceptable [15:10:01 CET] <fling> I don't see it in manpage [15:11:41 CET] <amosbird> it would be nice that ffmpeg can show a count down of delayed seconds ... [15:12:37 CET] <fling> amosbird: you could add a second audio stream with countdown as input and your speakers as output. [15:12:49 CET] <amosbird> fling: I don't follow [15:12:59 CET] <amosbird> audio... [15:13:01 CET] <amosbird> ok.. [15:13:13 CET] <amosbird> visual count down is way better [15:15:00 CET] <fling> amosbird: you could add a second video stream with countdown as input and a pipe to mpv as output :P [15:18:22 CET] <fling> iive: ok pipe helps and I'm getting less artifacts [15:18:35 CET] <fling> iive: could be related to the slow gpu! [15:19:06 CET] <iive> gpu? [15:20:01 CET] <iive> most likely reason for artifacts is if packets from the input stream are lost or dropped [15:20:09 CET] <iive> try without the framerate thing. [15:21:18 CET] <amosbird> fling: could you show me how to achieve that? [15:22:55 CET] <fling> amosbird: ffmpeg -i countdown.nut -c copy -f nut - | mpv -- - [15:23:05 CET] <fling> amosbird: mix it with your ffmpeg command [15:23:15 CET] <amosbird> hmm, [15:23:23 CET] <amosbird> how can I mix that into the region of my command? [15:23:34 CET] <fling> amosbird: https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs [15:23:48 CET] <amosbird> countdown.nut: No such file or directory [15:23:54 CET] <amosbird> I thought that's a thing.... [15:24:35 CET] <fling> amosbird: you need to record a countdown video. [15:27:17 CET] <fling> iive: x11 performance is really bad [15:27:24 CET] <amosbird> this doesn't work as expected [15:27:28 CET] <fling> iive: I can't get artifacts when running ffplay in a small window [15:27:45 CET] <amosbird> in fact I need a popup count down window [15:27:53 CET] <amosbird> do you know anything similar to that? [15:27:55 CET] <iive> fling, that's really strange [15:28:23 CET] <fling> iive: slow xorg slows down cpus [15:28:29 CET] <iive> what the artifacts look like ? [15:28:42 CET] <fling> like missing parts in h264 [15:29:36 CET] <iive> do you have xvideo working? `xvinfo` should display a lot of info (don't need details) [15:30:39 CET] <fling> X-Video Extension version 2.2 \n screen #0 \n no adaptors present [15:31:18 CET] <iive> so you have no hardware acceleration on the video card. [15:31:35 CET] <fling> Yes. [15:31:42 CET] <iive> what is the gpu? [15:32:12 CET] <fling> iive: VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 10) [15:33:29 CET] <fling> I see no artifacts with ffplay running at 1/6 of screen size! And not because my eyes are bad :D [15:35:23 CET] <fling> DHE: ^ looks like I figured it out. I hope this slow X is not causing any issues with my storage :P [15:35:31 CET] <fling> I need to stop using this gpu probably. [15:36:06 CET] <iive> don't worry, you are not using it :| [15:36:14 CET] <DHE> that's not a GPU. that's a VGA port that the IPMI controller can hijack as well [15:36:27 CET] <fling> There is also this one VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 760] (rev a1) [15:36:41 CET] <DHE> that one is at least presentable, if slightly old [15:36:48 CET] <fling> but it has no d-sub port, I need another monitor& [15:37:04 CET] <DHE> called it [15:40:15 CET] <fling> Why is it called aspeed? haha [15:40:37 CET] <iive> i think in latin "a" means "anti" [15:40:42 CET] <fling> I'm only getting ~2 fps with full screen mpv [15:40:52 CET] <fling> oh anti speed, sounds right. [15:40:59 CET] <iive> :) [15:41:30 CET] <iive> but honestly, s3virge had video overlay... [15:42:00 CET] <fling> &or I could install s3virge!! [15:42:20 CET] <iive> make sure you have 4MB :D [15:42:29 CET] <fling> No, I could not, the pike slot prevents me from using a single pci slot on this board, need a riser. [15:42:59 CET] <fling> Time to buy a better screen anyway. [15:43:11 CET] <iive> 1920*1080*1,5 ~= 3MB [15:43:51 CET] <iive> the slowdown probably comes from swscale conversion of yuv to rgb colorspace [15:44:13 CET] <iive> it might be done by a single thread and becoming bottleneck, causing dropped packets [15:54:47 CET] <fling> iive: also this -> `ffmpeg -f v4l2 -input_format h264 -video_size 1920x1080 -framerate 30 -i /dev/video0 -c copy -f nut /tmp/test.nut` gives me 15 fps on kgpe-d16 and 24 fps on x200 [15:55:06 CET] <fling> I should compare ffmpeg versions [15:56:00 CET] <iive> maybe move input parameters before -i ? [15:56:13 CET] <iive> oh, they are [15:56:30 CET] <iive> this should literally do no processing at all. [15:56:41 CET] <fling> kgpe-d16 one has libv4l disabled [15:56:44 CET] <fling> need to enable it [15:57:02 CET] <iive> isn't the cam usb ? [15:57:12 CET] <iive> doesn't the cam do the encoding? [15:57:29 CET] <fling> iive: it does. [15:57:54 CET] <iive> then it should just pass the encoded bitstream through the usb and that's it. [15:58:10 CET] <iive> even P2 should be able to handle it. [15:58:10 CET] <fling> iive: but ffmpeg sends it the parameters first [15:58:32 CET] <fling> This one is not a performance issue. [15:58:45 CET] <fling> It is the format issue. I'm getting wrong fps& [15:58:52 CET] <iive> oh [15:58:53 CET] <iive> ok [15:59:12 CET] <fling> probably because of disabled v4l, because on another box it runs better ;P [16:00:39 CET] <fling> iive: v4l-ctl says the device is capable of 30fps btw [16:00:57 CET] <fling> 24 is good too but still [16:02:02 CET] <fling> rebuilding did not help& [16:34:41 CET] <AutismeGutten> i have a bunch of video files with the naming scheme:IMG_<number>.MOV. I want to resize and rename these files. The commanf ffmpeg -i IMG_<number>.MOV -s 1280x720 output.mkv works for indivdual files but i want to mass convert them iwth the naming scheme <number>.mkv for instance [16:35:26 CET] <kepstin> AutismeGutten: write a shell script that runs ffmpeg multiple times in a loop. ffmpeg has no built-in batch operation support. [16:35:56 CET] <AutismeGutten> alright thanks [16:38:54 CET] <sparrowsword> how on earth do i get this line of code into python? "ffmpeg -f dshow -i video="Virtual-Camera" -preset ultrafast -vcodec libx264 -tune zerolatency -b 900k -f mpegts udp://10.0.0.193:8081" [16:40:04 CET] <kepstin> sparrowsword: https://docs.python.org/3/library/subprocess.html [16:40:43 CET] <sparrowsword> kepstin: right, but i need my python code to interact with the video/stream [16:40:54 CET] <kepstin> what do you mean by "interact with"? [16:40:59 CET] <sparrowsword> kepstin: im trying to use my webcam for a local stream [16:41:53 CET] <sparrowsword> kepstin: the goal is to use image recognition on my local stream, and my image classifier is in python [16:42:45 CET] <kepstin> sparrowsword: ok, so what you want to do is use ffmpeg as a way to read from the webcam and provide raw, decoded image frames to python? [16:43:11 CET] <sparrowsword> kepstin: yes, because the latency is basically none [16:43:38 CET] <kepstin> in that case, you'd probably want to build an ffmpeg cli that outputs raw video in your desired pixel format to stdout, and then run that command with Popen so you can read the frames into python. [16:44:17 CET] <sparrowsword> kepstin: like the line above? [16:44:41 CET] <kepstin> the example you gave streams video to an external server or application, that's quite different [16:45:35 CET] <sparrowsword> hmm ok [16:45:36 CET] <kepstin> something like "ffmpeg -f dshow -i video="Virtual-Camera" -pix_fmt yuv420p -f rawvideo -" is the command you want (don't run that in a terminal, that command outputs raw binary frame data to stdout) [16:47:07 CET] <fling> iive: the problem was in camera controls getting saved in camera itself [16:47:20 CET] <fling> iive: solved with v4l2-ctl [16:47:29 CET] <iive> \o/ [16:49:40 CET] <sparrowsword> kepstin: so i dont actually have a webcam on my computer... i do however have one on my phone, and i am using ip-webcam to locally stream, in this case do i use the line i posted? [16:54:40 CET] <kepstin> sparrowsword: replace the input stuff on that command line with whatever you need to get the video input... i don't know what you need. [16:54:55 CET] <sparrowsword> kepstin: nvm.. i think i remember... forgot to use requests... [16:55:01 CET] <sparrowsword> not a ffmpeg issue [17:35:30 CET] <sparrowsword> has anyone used ipwebcam with ffmpeg? [18:39:30 CET] <another> hmm.. anyone knows why ffv1 in mkv is muxed with codec id V_MS/VFW/FOURCC instead of V_FFV1 ? [19:19:07 CET] <amosbird> hmm, does ffmpeg provide a countdown clock to show the starting ? [19:19:11 CET] <amosbird> -ss [19:27:05 CET] <amosbird> can I make ffmpeg -f x11grab grab keyboard to quit early? [19:41:30 CET] <kepstin> another: as far as I know, matroska doesn't define a native method for muxing ffv1? so it's done via the fourcc compat. [19:41:51 CET] <JEEB> huh? [19:41:58 CET] <JEEB> pretty sure there was a native ID [19:42:33 CET] <JEEB> libavformat/matroska.c: {"V_FFV1" , AV_CODEC_ID_FFV1}, [19:43:06 CET] <kepstin> if there is, it's not on https://www.matroska.org/technical/specs/codecid/index.html or http://haali.su/mkv/codecs.pdf and I haven't been able to find any specs on how to do the muxing :/ [19:43:28 CET] <kepstin> then again, those are also missing opus [19:43:32 CET] <JEEB> they're standardizing FFV1 and FLAC in matroska for archival so probably cellar? [19:43:33 CET] <kepstin> so they're obviously out of date [19:43:49 CET] <JEEB> and yes, the listing on matroska.org definitely is lacking and the haali one was never updated [19:43:57 CET] <JEEB> also the HEVC one is only the matroska mailing list I think [19:45:20 CET] <another> found the commit responsible: https://github.com/FFmpeg/FFmpeg/commit/9ae762da7e256aa4d3b645c614fcd1959e1… [19:46:38 CET] <another> associated ticket: https://trac.ffmpeg.org/ticket/6206 [19:46:55 CET] <kepstin> ah, thanks to the pointer to cellar. There it is: https://tools.ietf.org/html/draft-ietf-cellar-codec-01 [19:47:25 CET] <kepstin> that draft has ffv1, but is still missing opus, heh [19:48:38 CET] <JEEB> another: ok, so nobody cared to implement the CodecPrivate for writing and thus ffv1 was special cased [19:48:44 CET] <JEEB> :psyduck: [21:11:12 CET] <ossifrage> Anyone know how to get the lowest latency playback out h.264 elementary streams with ffplay? '-sync ext -flags low_delay' seems to accumulate latency (it grew to ~1minute) [21:11:50 CET] <ossifrage> If I specify a frame rate with it starts out at ~1s but that seems to drift, just slowly [21:14:54 CET] <ossifrage> Actually with '-framerate 30', the latency starts out at 416ms [21:15:29 CET] <JEEB> the libraries definitely let you do low latency, but none of them are configured to be such by default [21:15:36 CET] <JEEB> since low latency is a rather specific use case [21:15:57 CET] <JEEB> basically you start with setting the video decoding threading to slice threads instead of frame threads first [21:16:11 CET] <ossifrage> JEEB, I'm only using ffplay for playback, the video is coming from a hardware encoder [21:16:21 CET] <JEEB> since you get a delay of THREAD_COUNT at the very minimum [21:16:28 CET] <JEEB> (for frame threaded decoding) [21:16:55 CET] <JEEB> with slice threads of course it's just slices of the same image being threaded [21:17:10 CET] <ossifrage> The 416ms is acceptable, but it seems to slowly accumulate latency and the hardware encoder only produces 30fps when there is enough light [21:17:13 CET] <JEEB> ossifrage: same goes for ffplay but I think that goes without saying :P [21:17:34 CET] <JEEB> also if your camera is VFR you definitely want to output stuff with timestamps [21:18:03 CET] <JEEB> if you want to try other things out, wm4 did implement this sort of stuff https://mpv.io/manual/master/#low-latency-playback [21:18:07 CET] <ossifrage> I'm not so worried about the threading or decoding in slices, I just want to minimize all the bitstream level buffering [21:18:26 CET] <JEEB> well threading with frame threads adds latency [21:18:27 CET] <JEEB> :V [21:18:28 CET] <ossifrage> JEEB, my next step is to use libavformat to add fmp4 [21:19:11 CET] <JEEB> for lavf you will have to set buffers etc [21:19:48 CET] <JEEB> but I've never optimized my stuff for this so good luck and have fun. I just know it's possible. [21:21:31 CET] <JEEB> but I recommend you make your own API client for your use case [21:24:12 CET] <ossifrage> JEEB, thanks, I didn't know about mpv, I always just use ffplay when dealing with elementary streams [21:26:10 CET] <ossifrage> I only just got the camera SOC to start spitting out frames early this morning, so having it playback with <1s latency is great [21:26:36 CET] <ossifrage> I'm not putting any effort to lower the latency on the encode side, I want the best video quality I can get out of the encoder for the bits [21:27:01 CET] <JEEB> if you're doing the encoding then I do recommend you put the stream into something that has timestamps [21:27:15 CET] <JEEB> so the reading side doesn't have to guesswork them [21:27:49 CET] <ossifrage> Yeah I have PTS in the metadata, but right now I'm just dumping out the elementary packs and none of the systems stuff [21:29:02 CET] <ossifrage> The encoder tracks the PTS from the point it captures the images from the sensor, so I can calculate the delay inside the hardware [21:31:01 CET] <ossifrage> Right now I'm just dumping the video to stdout and piping it over ssh to mpv [00:00:00 CET] --- Fri Feb 22 2019

1 0

ffmpeg-devel.log.20190220
by burek 21 Feb '19

21 Feb '19

[15:43:54 CET] Action: durandal_1707 wrote >3k lines of non-working code [15:53:13 CET] <atomnuker> send it to an online'd public printer [16:02:26 CET] <JEEB> :D [16:05:34 CET] <atomnuker> wow, the bitstream seems uber-corporate-y [16:05:53 CET] <atomnuker> all these descriptions no one is ever going to use [16:06:23 CET] <JEEB> yea, it's got a crapload of stuff [16:06:55 CET] <atomnuker> quantization looks pretty much like atrac9, but is segmented like aac (sce, cpe elements) [16:07:19 CET] <atomnuker> I was expecting something to measure up to opus, not something which looks like it would sound worse than ac3 [16:21:34 CET] <durandal_1707> atomnuker: you did blind test on atrac9 ? [16:27:50 CET] <atomnuker> no, just looking at the code [16:36:33 CET] <philipl> BtbN: So, I was provoked to do more digging yesterday about the implications of compiling cuda kernels with the sdk vs licencing. [16:37:32 CET] <philipl> The first thing I realised is that when we do ptx compilations, it's not compiling to a binary form, but a virtual assembly format. And then that is compiled to binary at runtime to match the physical hardware. [16:37:47 CET] <philipl> So there's nothing linked in during the ffmpeg build. [16:39:17 CET] <philipl> So if the filter code is written against the dynamic loader, then the ffmpeg binary code is still lgpl compatible, and the ptx files, which are aggregated and not linked, don't include anything from the sdk. The compiler was used and that's it. It's the same as compiling with vc++. [16:39:23 CET] <philipl> Do you buy that? [17:58:41 CET] <cone-842> ffmpeg 03Jan Sebechlebsky 07master:87d5686151bc: avcodec/bsf: Add ff_bsf_get_packet_ref() function [17:58:42 CET] <cone-842> ffmpeg 03Nikolas Bowe 07master:aaf7fd168050: avcodec/extract_extradata_bsf: Fix leak discovered via fuzzing [17:58:43 CET] <cone-842> ffmpeg 03James Almer 07master:be65995d23c9: avcodec/extract_extradata: Zero-initialize the padding bytes in all allocated buffers [17:58:44 CET] <cone-842> ffmpeg 03James Almer 07master:70f11ee9981f: avcodec/extract_extradata: Do not allocate more space than needed when removing NALUs in h264/hevc [17:58:45 CET] <cone-842> ffmpeg 03James Almer 07master:6442d8bad680: avcodec/extract_extradata: Move the reference in the bsf internal buffer [17:58:46 CET] <cone-842> ffmpeg 03James Almer 07master:3365e91b1ed8: avcodec/extract_extradata: don't uninitialize the H2645Packet on every processed packet [17:58:47 CET] <cone-842> ffmpeg 03James Almer 07master:97c9a5084479: avcodec/libaomenc: remove AVOption related to frame partitions [17:58:48 CET] <cone-842> ffmpeg 03James Almer 07master:04e8b8b0530e: avcodec/libaomenc: export the Sequence Header OBU as extradata [17:58:49 CET] <cone-842> ffmpeg 03Martin Storsjö 07master:5584abf69d83: arm: Emit .thumb_func directives [17:58:50 CET] <cone-842> ffmpeg 03Zhong Li 07master:4c5e77e0bf14: lavc/qsvenc_jpeg: add async_depth support [17:58:51 CET] <cone-842> ffmpeg 03Zhong Li 07master:1ff6cb2ca665: lavc/qsvenc_jpeg: set a default quality [17:58:52 CET] <cone-842> ffmpeg 03James Almer 07master:493240a522fc: Merge commit '97c9a5084479eeb66f4beb100cc7589a2c8bfe81' [17:58:53 CET] <cone-842> ffmpeg 03James Almer 07master:a024c3ce9a50: Merge commit '04e8b8b0530e2aa33010faba3d0b6b6c9c5b704e' [17:58:54 CET] <cone-842> ffmpeg 03James Almer 07master:22b6e1011caa: doc/libav-merge: add a line about the previous skipped merge [17:58:55 CET] <cone-842> ffmpeg 03James Almer 07master:b2f32d60eeaf: Merge commit '5584abf69d83169a010aca404cd1cf95c23ad9ef' [17:58:56 CET] <cone-842> ffmpeg 03James Almer 07master:bec3b2041dcc: Merge commit '1ff6cb2ca6652e7d2a929afd33d8ed6268c45568' [18:08:14 CET] <cone-842> ffmpeg 03James Almer 07master:cacb62f9cbf3: Revert "decode: copy the output parameters from the last bsf in the chain back to the AVCodecContext" [18:08:15 CET] <cone-842> ffmpeg 03James Almer 07master:8d80046a0ff7: libaom: remove references to yuva444p pixfmt [18:08:16 CET] <cone-842> ffmpeg 03Martin Storsjö 07master:a3a501df240f: libavutil: Undeprecate the AVFrame reordered_opaque field [18:08:18 CET] <cone-842> ffmpeg 03Martin Storsjö 07master:80f85a95da29: libx264: Pass the reordered_opaque field through the encoder [18:08:18 CET] <cone-842> ffmpeg 03Carl Eugen Hoyos 07master:ee3f62a90caa: pixfmt: Add GRAY10 [18:08:19 CET] <cone-842> ffmpeg 03Carl Eugen Hoyos 07master:f149a4a5fc5a: swscale: Add GRAY10 [18:08:20 CET] <cone-842> ffmpeg 03James Almer 07master:9bf9358b615d: avcodec: libdav1d AV1 decoder wrapper. [18:08:21 CET] <cone-842> ffmpeg 03Linjie Fu 07master:e716323fa852: qsvenc: Add VDENC support for H264 and HEVC [18:08:22 CET] <cone-842> ffmpeg 03James Almer 07master:56f50183f380: libdav1d: fix build after a recent API break [18:08:23 CET] <cone-842> ffmpeg 03James Almer 07master:70ab2778be9c: libdav1d: update API usage to the first stable release [18:08:24 CET] <cone-842> ffmpeg 03James Almer 07master:6fc762b4fd2c: Merge commit '70ab2778be9c83dab84340af7e3ba83fa0f98576' [18:08:55 CET] <JEEB> gg [18:12:27 CET] <jamrial> bunch of noops for now. the "fun" comes later [18:49:57 CET] <cone-842> ffmpeg 03Luca Barbato 07master:90adbf4abf33: cook: Use the correct table for 6-bit stereo coupling [18:49:58 CET] <cone-842> ffmpeg 03James Almer 07master:ca44fa5d7fda: avcodec/libdav1d: properly free all output picture references [18:49:59 CET] <cone-842> ffmpeg 03Martin Storsjö 07master:41cf3e3b1ca3: arm: Create proper .rdata sections for COFF [18:50:00 CET] <cone-842> ffmpeg 03James Almer 07master:0c126431f9b2: Merge commit '90adbf4abf336f8042aecdf1e18fdf76a96304b1' [18:50:01 CET] <cone-842> ffmpeg 03James Almer 07master:cd8087444bb4: Merge commit 'ca44fa5d7fda7e954f3ebfeb5b0d6d1be55fcaa3' [18:50:02 CET] <cone-842> ffmpeg 03James Almer 07master:ebdc5c419aef: Merge commit '41cf3e3b1ca375962951fde1b90a03b16197d205' [19:15:08 CET] <fjant> hi [19:16:39 CET] <fjant> any plans of updating doc/examples folder? Many files use deprecated apis. E.g. demuxing_decoding.c and avcodec_decode_video2(). What is the proper way? [19:17:11 CET] <JEEB> I think there recently was a patch to one of the examples, but I didn't have time to look at it [19:17:31 CET] <JEEB> the newer decoding/encoding APIs are rather alright documented @ https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [19:18:16 CET] <JEEB> IIRC the transcoding example (which does demux & decode as well) was already updated by someone if I recall correctly (or possibly it's new enough to have been made like that) [19:20:16 CET] <fjant> That document looks rather promising! Thank you! [19:40:32 CET] <cone-842> ffmpeg 03Janne Grunau 07master:bb515e3a735f: h264/aarch64: sign extend int stride in loop filter asm [19:40:33 CET] <cone-842> ffmpeg 03Janne Grunau 07master:d7f4f5c4a18a: checkasm/h264: add loop filter tests [19:40:34 CET] <cone-842> ffmpeg 03James Almer 07master:5ca7eb36b735: Merge commit 'bb515e3a735f526ccb1068031e289eb5aeb69e22' [19:40:35 CET] <cone-842> ffmpeg 03James Almer 07master:d5d699ab6e6f: avcodec/h264dsp: change loop filter stride argument to ptrdiff_t [19:40:36 CET] <cone-842> ffmpeg 03James Almer 07master:f32d29395557: Merge commit 'd7f4f5c4a18a0c9e62635cfa6fe8a9302b413c01' [19:47:03 CET] <cone-842> ffmpeg 03Janne Grunau 07master:846c3d6aca54: h264/aarch64: optimize neon loop filter [19:47:04 CET] <cone-842> ffmpeg 03Janne Grunau 07master:28a8b5413b64: h264/aarch64: add intra loop filter neon asm [19:47:05 CET] <cone-842> ffmpeg 03Martin Storsjö 07master:eec93e57096a: libopenh264dec: Use a newer decoding entry point function [19:47:06 CET] <cone-842> ffmpeg 03James Almer 07master:4dc1f06f0c84: Merge commit '846c3d6aca5484904e60946c4fe8b8833bc07f92' [19:47:07 CET] <cone-842> ffmpeg 03James Almer 07master:e4e04dce1fab: Merge commit '28a8b5413b64b831dfb8650208bccd8b78360484' [19:47:08 CET] <cone-842> ffmpeg 03James Almer 07master:f05f210526a3: Merge commit 'eec93e57096aa4804862d62760442380c70d489b' [19:52:14 CET] <cone-842> ffmpeg 03Janne Grunau 07master:156ea66c91b1: h264/x86: sign extend int stride in deblock functions [19:52:16 CET] <cone-842> ffmpeg 03Sven Dueking 07master:90b15f60bf49: srt: Set srto_sender flag to sender srt socket [19:52:17 CET] <cone-842> ffmpeg 03James Almer 07master:0a319bcce571: Merge commit '156ea66c91b1986a87916f187216978d686725f6' [19:52:18 CET] <cone-842> ffmpeg 03James Almer 07master:1811b7d1f533: Merge commit '90b15f60bf4919deaed66d868e18107eba371da7' [21:15:59 CET] <cone-842> ffmpeg 03Adam Sampson 07master:bfa33f548db8: lavf/jacosubdec: compute subtitle duration correctly [21:16:00 CET] <cone-842> ffmpeg 03Ruiling Song 07master:dfde416ea8d0: MAINTAINERS: add myself for tonemap_opencl [21:53:21 CET] <cone-842> ffmpeg 03Lou Logan 07master:6bfda984b3d0: doc/mailing-list-faq: add Mail Delivery info [21:53:29 CET] <durandal_1707> atomnuker: could you tell me how would you derive max_quant_idx[g][sfb] array in AC-4 by looking in specification? I'm thinking my approach might not be correct [22:04:31 CET] <atomnuker> are the specs up somewhere? [22:07:33 CET] <durandal_1707> atomnuker: https://www.etsi.org/deliver/etsi_ts/103100_103199/10319001/01.03.01_60/ts_… [22:08:47 CET] <durandal_1707> atomnuker: see also https://github.com/richardpl/FFmpeg/tree/ac4 [22:17:35 CET] <atomnuker> yeah, max_quant_idx[g][i] looks correct in case there are only 4 codebook dims [22:52:35 CET] <durandal_1707> atomnuker: this codec is big pile of stinking baloons with elephants inside them - the binary code for asf_spectral_data is clearly different - it does not use divisions and multiplications but only & and >> operations [23:13:59 CET] <cone-842> ffmpeg 03Michael Niedermayer 07master:5ccf296e7472: avcodec/h264_direct: Fix overflow in POC comparission [23:42:00 CET] <cone-842> ffmpeg 03James Almer 07master:aa844dc46f93: aarch64/h264dsp: change loop filter stride argument to ptrdiff_t [23:42:01 CET] <cone-842> ffmpeg 03James Almer 07master:7b9ca44cbca4: arm/h264dsp: change loop filter stride argument to ptrdiff_t [23:42:02 CET] <cone-842> ffmpeg 03James Almer 07master:72458b3f0828: ppc/h264dsp: change loop filter stride argument to ptrdiff_t [23:57:29 CET] <cone-842> ffmpeg 03Carl Eugen Hoyos 07master:7e4d3dbe18ce: lavc/aarch64/h264dsp_init: Only use neon horizontal intra loopfilter for 4:2:0. [00:00:00 CET] --- Thu Feb 21 2019

1 0

ffmpeg.log.20190220
by burek 21 Feb '19

21 Feb '19

[03:11:24 CET] <giaco> kepstin: I've tried "loudnorm=I=-18,aresample=48000" but ffmpeg crashed complaining about missing channel data so I fixed it with "loudnorm=I=-18,aresample=48000,aformat=channel_layouts=mono". The output is audible but wrong, speed seems wrong and some parts seems overlapping. I've also tried, just for test, just "loudnorm=I=-18" but again the output feels wrong. Removing the filter I've the stream sounds [03:11:26 CET] <giaco> right (except volume, obviously) [03:12:24 CET] <giaco> sorry for messed up english, I surely need some sleep [03:13:06 CET] <kepstin> hmm. your input is mono, right? [03:13:16 CET] <kepstin> i wonder if the loudnorm filter is just buggy with mono input [03:14:16 CET] <kepstin> you can try setting the "dual_mono" option on loudnorm to "true", maybe that will help? [03:16:55 CET] <giaco> kepstin: correct, input is mono [03:19:12 CET] <giaco> kepstin: I don't know how to chain internal filter options. "loudnorm=I=-18,aresample=48000" > "loudnorm=I=-18,dual_mono=true,aresample=48000" ? [03:27:17 CET] <giaco> got it [03:38:34 CET] <giaco> but same error "Cannot select channel layout for the link between filters Parsed_aresample_1 and format_out_0_0." [03:38:38 CET] <zap0> hi.. anyone know what it means when a YUV image appears very pink and green [03:39:01 CET] <giaco> I think I have to add same "aformat=channel_layouts=mono" [03:39:08 CET] <giaco> or maybe "aformat=channel_layouts=stereo" now [03:41:53 CET] <giaco> kepstin: no, audio chunks are overlapped even with "-af loudnorm=I=-18:dual_mono=true,aresample=48000,aformat=channel_layouts=stereo" [03:45:57 CET] <kepstin> zap0: can't really say without more info, but some common mistakes are that you got the U and V (well, Cr and Cb) planes reversed, or you're interpreting the YUV colours as if they were RGB [03:46:31 CET] <kepstin> giaco: what ffmpeg version? [03:47:04 CET] <giaco> same problem even with "-af loudnorm=I=-18:dual_mono=true,aresample=48000,aformat=channel_layouts=mono" chunks are overlapped, I can hear my voice twice [03:47:34 CET] <zap0> i have written some unit tests for my routines and they appear to be correct. i also tried swapping the U and V channels, but i still get very green and pink images. [03:47:36 CET] <giaco> kepstin: ffmpeg version 4.1-static [03:47:45 CET] <zap0> it looks like this type of mistake https://stackoverflow.com/questions/33542708/camera2-api-convert-yuv420-to-… [03:48:55 CET] <kepstin> right, so you have some mistake in how you're interpreting the image buffer. what pixel format is it in? [03:49:29 CET] <kepstin> you might want to just use libswscale to convert to rgb or whatever rather than attempting to do it yourself. [03:49:39 CET] <zap0> YUY2 (i think) [03:50:06 CET] <zap0> which is a 4:2:2 [03:50:56 CET] <zap0> the pixel are in the right spot, i can clearly make out the video footage.. so the geometry is not wrong. it's the colours [03:51:00 CET] <kepstin> fun, that's a packed format [03:51:07 CET] <giaco> I think that the problem could be elsewhere. Maybe the transform/filter speed is not fast enought to process all the data and chunks are lost [03:51:31 CET] <kepstin> giaco: ah, that could be if you have a realtime source. the loudnorm filter is kind of slow [03:51:45 CET] <kepstin> giaco: try that on a local file and see if it runs at >1.0x speed [03:52:18 CET] <giaco> kepstin: without filter I have speed= 1.1x, with filter is 0.32x! :( [03:52:39 CET] <kepstin> giaco: wow, what kind of processor is this? :/ [03:53:42 CET] <kepstin> zap0: can you give me some more context on what you're trying to do? is the YUY2 data input? output? how is ffmpeg involved? [03:54:01 CET] <giaco> kepstin: shitty android phone. I am testing on a low end device (min target) [03:54:31 CET] <kepstin> ah, slow arm device. yeah, i wouldn't even bother with doing any live stuff on something like that [03:54:46 CET] <kepstin> giaco: just give up on the volume normalization, not worth it on a device like that [03:54:58 CET] <giaco> kepstin: I should have though about that much earlies, but the android profiler is was misleading, it shows no more than 10% cpu occupation during transform [03:56:16 CET] <kepstin> zap0: note that ffmpeg's name for the YUY2 pixel format is "yuyv422" [03:56:40 CET] <giaco> kepstin: I fill fallback to user-selected amplification [03:56:55 CET] <giaco> and save the loudnorm for high-end devices [03:57:15 CET] <zap0> might have figured somethign out... back in 5 [03:57:19 CET] <giaco> no info has been lost. Thanks for being patient [03:58:01 CET] <kepstin> giaco: honestly for devices like that, you'd really want to be doing all the transcoding work on the server you're streaming media to, rather than the device itself [03:58:36 CET] <kepstin> but hmm. is this targetting a chromecast on lan use case, or something like that? [03:59:15 CET] <kepstin> for that type of thing, yeah, I guess just having a manually controlled volume is what you can do. [03:59:41 CET] <zap0> kepstin: endian issue! thanks. i was interpreting YUYV as UYVY fixed! [04:00:09 CET] <kepstin> zap0: yeah, that would do it - treating the colour as lightness and vice-versa :) [04:00:21 CET] <zap0> oops, i meant YUYV VYUY [04:00:32 CET] <zap0> much thanking you! [04:01:49 CET] <zap0> now i need to learn YV12 and V210 [04:04:03 CET] <kepstin> yv12 is easy enough, it's just yuv420p with the u and v swapped :) [04:04:56 CET] <zap0> i hope it's that easy! surely there is more to it than that [04:16:04 CET] <zap0> https://wiki.multimedia.cx/index.php/V210 this looks to be a bit tricky. [04:27:27 CET] <zap0> most of the YUV integer code i have is all 8bit. V210 is 10bit. [04:31:20 CET] <kepstin> ... so why aren't you just using libswscale to convert these? [04:33:17 CET] <kepstin> or checking out something like mpv, which has gpu (opengl) versions of these conversions? [10:17:50 CET] <TyrfingMjolnir> How can I use ffmpeg to make a new video file based on a time range within an existing file? [12:53:04 CET] <khaleb> Hello here [13:00:32 CET] <w1kl4s> general kenobi! [13:02:32 CET] <khaleb> i'm newbie [13:03:30 CET] <khaleb> i have a problem with straming on windows [13:03:48 CET] <khaleb> can someone help me pleases ? [13:04:45 CET] <norbert> khaleb: as the topic of this chat channel states, "When asking a question be precise, detailed and patient." [13:04:55 CET] <norbert> "a problem with staming" is pretty vague [13:05:34 CET] <norbert> could be a million different things, maybe you have your monitor turned off so you cannot see the stream; maybe turn your monitor on [13:19:05 CET] <khaleb> Yes ofcourse, sorry. [13:21:00 CET] <khaleb> I have a question fisrt: Is it possible to re-stream a rtmp stream to UDP output using ffmpeg ? [13:51:49 CET] <norbert> at http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide is that correct, /dev/null [13:51:58 CET] <norbert> or should that be > /dev/null, with the ">" [13:52:10 CET] <norbert> because when I run the command, ffmpeg asks if I want to overwrite /dev/null... [13:52:53 CET] <furq> you can ignore that warning, but you can probably just use -f null - [13:53:08 CET] <furq> unless webm encapsulation is somehow critical for the pass file, which it probably isn't but idk [13:53:57 CET] <furq> also that guide predates -row-mt which is the recommended multithreading method now [13:55:02 CET] <norbert> ok [14:02:41 CET] <norbert> how necessary/useful is the first pass for a website similar to YouTube? [14:02:58 CET] <norbert> because that first pass takes time, I wonder if it's worth the processing time [14:07:24 CET] <norbert> hm, actually, I see the second pass takes longer, so maybe a more pressing question is, how would I prevent the transcode queue from becoming larger and larger; if one user uploads 10 720p videos, the next user may already have to wait 60+ minutes [14:08:07 CET] <norbert> in theory I could run ffmpeg in parallel, but it'd still only have the max CPU cores working on it [14:09:08 CET] <norbert> and my plan is to encode each upload to 360, 480, 720 and 1080p [14:09:35 CET] <norbert> to all switching quality (for mobile, desktop, different network speeds, etc) [14:09:39 CET] <norbert> *allow [14:10:43 CET] <norbert> I mean, damn, the second pass is still going, and it's only at 01:43 [14:10:58 CET] <norbert> and that's just the 720p at 15fps [14:11:45 CET] <norbert> I guess this answers what I was wondering about why many existing video CMS'es don't transcode [14:27:13 CET] <kepstin> youtube can do it because they have ridiculous amounts of compute power [14:27:34 CET] <kepstin> also they usually don't have the vp9 available immediately, it takes longer to get ready than other formats [14:28:47 CET] <norbert> when I'm running the first pass with "Constrained Quality Recommended Settings" I see that ffmpeg is using only ~125% of my CPU, is there any way to increase this? [14:29:31 CET] <norbert> because I have more compute power :) [14:30:25 CET] <norbert> my plan is to make the 360p available first, then work on the rest after that [14:46:38 CET] <norbert> hm, encoding still takes about a second for each in-video second, even if I encode to 640x360; this means if someone uploads 5 videos of an hour, the next user has to wait at least 5 hours - and that's if I only encode to 360p [14:46:50 CET] <norbert> there has to be a way to make this much faster [14:46:57 CET] <furq> libvpx is really slow [14:47:17 CET] <norbert> is there a good alternative I could use for a video CMS? [14:47:33 CET] <furq> not if you think you'd have to pay to use h264 [14:48:16 CET] <furq> vpx is generally terrible at multithreading, so youtube just splits videos into multiple segments and then distributes the encoding [14:48:18 CET] <norbert> would paying for h264 be on a per video basis? [14:48:58 CET] <norbert> that's interesting, splitting the video; would become a bit too technical for my okay-but-not-awesome skills [14:49:48 CET] <furq> i've never bought an h264 license but iirc it's free if you're not making money from the videos [14:50:09 CET] <furq> and it's also free if you're not in a jurisdiction where software patents exist, e.g. the EU [14:50:28 CET] <furq> at least in theory [14:50:51 CET] <DHE> which is interesting because there are ads on youtube... [14:50:52 CET] <furq> i phrased that confusingly. the eu is a jurisdiction where software patents don't exist [14:52:09 CET] <norbert> I'm in the EU and won't be making money from the video, so I guess h264 would be an option [14:52:45 CET] <furq> if you don't think you need a license then x264 is generally much nicer to use [14:53:17 CET] <norbert> ok; I think Google uses VP9 with Opus for YouTube though? [14:53:28 CET] <furq> alongside h264 and aac, yeah [14:53:49 CET] <DHE> for high resolution and quality, yes. vp9 is superior to h264 so there's an incentive to serve it [14:54:05 CET] <furq> most youtube videos are only in h264 [14:54:13 CET] <furq> because most youtube videos have like 500 views and they never get upgraded [14:55:01 CET] <furq> also vp9 is superior to h264 but libvpx is less superior to x264 [14:55:33 CET] <furq> certainly if you don't have google infra where you can just throw 100 cpus at encoding a single video at acceptable quality within 24 hours [14:59:11 CET] <norbert> 24 minutes, I think you meant [14:59:14 CET] <norbert> libx264 is definitely much faster (just tried) [14:59:31 CET] <furq> nah i meant hours [14:59:41 CET] <furq> even for fairly popular videos there's a huge lag time for the vp9 version to show up [14:59:49 CET] <norbert> ok [15:00:35 CET] <DHE> when I upload videos at 70+ megabits processing times get really long. google really takes every trick they can to encode quickly and uploading a video fast steals one of their tricks away from them... [15:01:21 CET] <norbert> because they can't start processing while upload is still in progress, you mean? [15:01:40 CET] <norbert> furq: which audio could you suggest I use with -f mp4? [15:01:43 CET] <furq> aac [15:01:47 CET] <norbert> ok [15:02:00 CET] <furq> you would need to have an h264/aac fallback anyway for apple devices [15:02:04 CET] <furq> which refuse to support anything google made [15:02:21 CET] <furq> but everything else supports h264/aac in mp4 so you might as well just use that [15:03:03 CET] <norbert> libx264 (-f mp4) is h264? [15:03:11 CET] <DHE> norbert: because they start transcoding immediately. if I upload the same video at 7 megabits, they have 10x the amount of time to do transcoding during the upload which potentially buys them a lot of time to "make it available as soon as possible" [15:03:23 CET] <norbert> DHE: right [15:03:44 CET] <DHE> in ffmpeg you can specify which encoder to use, not just the target codec family. libx264 is a software encoder. but there's also options like quicksync, nvidia's GPU encoders, etc. in this case you're explicitly selecting software encoding [15:10:01 CET] <norbert> I have to say, "ultrafast will save 55% at the expense of much lower quality", that much lower quality still looks good to me [15:12:46 CET] <norbert> although I guess I can't ignore how large the files will be [15:13:57 CET] <norbert> hm, I feel a bit like I'm inventing the wheel; you'd think someone would have written down what I'm trying to find [15:14:49 CET] <DHE> the presets don't directly affect file size. file size can't be predicted unless you use CVR or VBV bitrate mode [15:15:16 CET] <DHE> in theory qp or crf mode will produce larger file sizes at faster presets, but it's not quite as simple as that either [15:32:50 CET] <norbert> furq: how does this look? ffmpeg -i <source> -c:v libx264 -crf 28 -preset veryslow -tune fastdecode -profile:v baseline -level 3.0 -movflags +faststart -c:a aac -ac 2 -ar 44100 -ab 64k -threads 0 -profile:v high -level 4.2 -movflags +faststart -tune zerolatency -f mp4 -vf scale=640:360 output.mp4 [15:34:09 CET] <norbert> encodes at an acceptable speed, should be iPhone compatible; then if I see the queue has no more 640x360 to do I can move on to higher qualities, after each checking if there's a 360p todo first [15:34:11 CET] <DHE> you have -tune and -profile:v set twice [15:34:32 CET] <norbert> oh yeah [15:35:16 CET] <furq> you don't need baseline for iphone compat and it'll hurt the quality a lot [15:35:46 CET] <norbert> yes, I meant to use just: -profile:v high -level 4.2 [15:35:47 CET] <furq> and you should absolutely not use zerolatency [15:35:53 CET] <DHE> baseline hasn't been needed for iphone compat since, what, iphone 4? [15:35:57 CET] <norbert> for iPad Air and iPhone 5s +newer [15:36:36 CET] <furq> also you probably want to actually set a scaler or else it'll use bicubic [15:36:45 CET] <furq> e.g. -vf scale=640:360:flags=lanczos [15:37:16 CET] <norbert> ok, thanks [15:40:23 CET] <norbert> I also had "-movflags +faststart" twice :P [15:53:55 CET] <norbert> thanks again furq, DHE; I'm happy with the speed and result that I managed to find [15:54:11 CET] <norbert> now on to coding the rest of the website :) [16:41:03 CET] <Ducky^> I have two video outputs at 800x600 each on Ubuntu [16:41:10 CET] <Ducky^> I'd like to capture both of them side by side with ffmpeg [16:41:29 CET] <Ducky^> ffmpeg -f x11grab -y -r 60 -s 1600x600 -i :0.0 -minrate 4000k -maxrate 4000k -vcodec h264 out.mkv [16:41:41 CET] <Ducky^> this command only captures the left screen and not the right (it's blank) [16:41:49 CET] <Ducky^> can I capture both? [16:45:18 CET] <DHE> does the $DISPLAY variable of both screens match? if not, no that wouldn't work [16:46:11 CET] <Ducky^> they should both be on the same display [16:46:50 CET] <Ducky^> I configured the resolution with xrandr and display as :0 for both screens, so they must be [16:53:19 CET] <norbert> Ducky^: maybe use kdenlive instead? [16:53:24 CET] <DHE> right, but it's possible to have :0.0 and :0.1 on the same X server [16:54:25 CET] <Ducky^> hmm, I had a try opening :0.1 and get -f x11grab -s "4480x1440" -r "30" -i :0.0 \ [16:54:28 CET] <Ducky^> -vcodec libx264 -s "1280x720" -preset slow [16:54:36 CET] <Ducky^> nope, not that [16:54:39 CET] <Ducky^> Cannot open display :0.1, error 6. [16:55:02 CET] <Ducky^> norbert: I was hoping for a command line way, I'm doing it with ssh [16:57:12 CET] <relaxed> Ducky^: -s and -r are not input options, see ffmpeg-h demuxer=x11grab [16:58:10 CET] <relaxed> Ducky^: er, ffmpeg -h demuxer=x11grab [16:59:38 CET] <Ducky^> thanks relaxed [17:00:04 CET] <Ducky^> I'm having some luck using the inbuilt gnome screen recorder, it captures both screens [17:00:06 CET] <Ducky^> so I'll use that [17:06:05 CET] <ralfie> hey, I'm trying to overlay two videos, where the base video starts 5 seconds after the overlay video [17:06:17 CET] <ralfie> but the overlay video freezes at frame 5s [17:06:23 CET] <ralfie> https://pastebin.com/bjne2y1H [17:07:11 CET] <ralfie> what i mean is, it shows the same frame from 0s to 5s (start of base video), then overlay proceeds as normal [17:08:39 CET] <ralfie> any conventional approach to this? perhaps by adding 5 seconds of black frames to the start of the base video, if there is no other solution? [17:15:51 CET] <norbert> ralfie: if it doesn't need to be command-line/automated, you could use kdenlive [17:16:06 CET] <norbert> overlaying videos sounds like a video editing thing [17:17:04 CET] <ralfie> im looking for an automated solution, i'll have one base video and a lot of overlaying videos [17:17:10 CET] <norbert> ok [17:18:04 CET] <norbert> my notes about adding a watermark include: ffmpeg -sameq -i out.ogv -ss 0 -t 30 -s 240x160 -ab 128k -deinterlace -r 25 -vf "movie=240x160_25p.png [logo]; [in][logo] overlay=main_w-overlay_w:main_h-overlay_h [out]" output.avi [17:18:11 CET] <ralfie> an overlaying video has 5 seconds of non-transparent content, then a chroma-keyed transition into the base video [17:18:20 CET] <norbert> (no idea if that's useful for you though) [17:18:29 CET] <ralfie> ooo [17:19:42 CET] <ralfie> don't think it's useful to me, but thanks [17:20:35 CET] <ralfie> i've tried splitting the overlay into a non-transparent and transparent part like so https://pastebin.com/j4bQhN5V [17:21:45 CET] <ralfie> seemed to work fine video-wise, but the audio tracks would behave weirdly [17:21:51 CET] <ralfie> couldn't stitch them back together exactly [17:21:54 CET] <ralfie> also no idea how efficient this is [17:33:46 CET] <ralfie> i guess i could fix that by adding the overlay as an input the 3rd time, and just using the audio from that, although that feels really hacky [17:48:51 CET] <Water_27300935_> Hi, I install ffmpeg on Fedora via source , but I can't find/run ffplay after install done. [17:49:27 CET] <pink_mist> did you have the proper SDL libraries and their headers on your system where ffmpeg's configure could find them? [17:49:38 CET] <Water_27300935_> ffmpeg and ffprobe is work [17:49:48 CET] <pink_mist> yes, but ffplay requires SDL [17:50:06 CET] <Water_27300935_> Oh, I try later. [17:50:16 CET] <Water_27300935_> :) [19:05:26 CET] <Water_27300935_> I reinstsll ffmpeg after install 'SDL' and 'SDL-devel', ffplay n't work continually, (in project folder can't find 'ffplay' execute file), [19:06:20 CET] <Water_27300935_> I use './configure','make','make install' to build ffmpeg, need some other option ? [19:07:21 CET] <DHE> is it specifically SDL version 2? [19:08:00 CET] <Water_27300935_> Oh, installed SDL only, not SDL2. [20:28:03 CET] <Water_27300935_> ffplay work after install SDL2, why have n't some notice or error while build ffmpeg without SDL2 ? [20:28:35 CET] <JEEB> did you specifically specify --enable-sdl? [20:32:12 CET] <Water_27300935_> Oh,no. [20:32:50 CET] <JEEB> the default in FFmpeg generally tends to be that unless you lack something that probably is considered "required" for the whole framework, then you get a failure without any options [20:32:54 CET] <JEEB> otherwise then there's two lists [20:33:05 CET] <JEEB> one where libraries that get autodetected and get enabled [20:33:20 CET] <JEEB> and another where you have to specify the enable-xxx yourself [20:33:29 CET] <JEEB> although I don't remember the details [20:33:46 CET] <JEEB> now, if you set --enable-blah yourself (in various cases) it will fail hard if it can't be found [00:00:00 CET] --- Thu Feb 21 2019

1 0

ffmpeg-devel.log.20190219
by burek 20 Feb '19

20 Feb '19

[06:23:04 CET] <cone-706> ffmpeg 03hwren 07master:8754147db668: lavc/libxavs2: remove unused context parameter [06:23:04 CET] <cone-706> ffmpeg 03hwren 07master:11751f62520b: lavc/libxavs2: use upper layer qp parameters first [06:23:04 CET] <cone-706> ffmpeg 03hwren 07master:ff03418348dd: lavc/libdavs2: fix parameter setting error [08:23:57 CET] <j-b> 'morning [09:43:57 CET] <JEEB> wow [09:44:24 CET] <JEEB> sub2video 100% depends on the subtitle codec context not being set proper during the first frame [09:45:10 CET] <nevcairiel> everyone knows that sub2video is a bit of a hack :) [09:45:13 CET] <JEEB> and if you have enough threads to have the subtitle decoder get its first frame and thus context width/height at the first frame fed to the filter chain [09:45:28 CET] <JEEB> I was wondering why I was getting different results between 6 and 7 threads [09:45:54 CET] <JEEB> sub2video: Generating AVFrame: (ist->sub2video: 1920x1080, dec_ctx: [-0x0)-]{+720x576)+} -> [-1920x1080-]{+720x576+} [09:45:57 CET] <JEEB> sub2video: Feeding a [-1920x1080-]{+720x576+} AVFrame with pts 1441 to filter: graph 0 input from stream 0:2 [09:46:07 CET] <JEEB> first one is working one, second is non-working [10:01:44 CET] <JEEB> then after the initial frame is fed, `sub2video: Generating AVFrame: (ist->sub2video: 1920x1080, dec_ctx: 720x576) -> 720x576` [10:01:50 CET] <JEEB> so it actually starts feeding the smaller things [10:02:16 CET] <JEEB> [auto_scaler_0 @ 0x35e3a00] w:720 h:576 fmt:bgra sar:0/1 -> w:1920 h:1080 fmt:yuva420p sar:0/1 flags:0x2 [10:02:19 CET] <JEEB> ^ and this happens [10:04:06 CET] <JEEB> nevcairiel: and yes, it's a total hack but it still keeps surprising me [10:19:23 CET] <JEEB> I guess scale2ref never gets hit proper or something [10:24:02 CET] <durandal_1707> wut? [10:25:04 CET] <JEEB> durandal_1707: figuring out how sub2video ends up not scaling things xD [10:51:38 CET] <JEEB> ok, manually inserting scale2ref seems to be the thing to do [10:52:19 CET] <JEEB> [dem_subs_stream][yadif_out]scale2ref[s2ref_subs][s2ref_video];[s2ref_video][s2ref_subs]overlay[overlay_out] [10:56:02 CET] <JEEB> might just make a bug report about this sample, but it seems like this is how sub2video is supposed to work [10:56:24 CET] <JEEB> the behavior differs heavily if you get your subtitles or not at the point of start [10:56:41 CET] <JEEB> +unfortunately, the behavior differs... [11:33:33 CET] <BtbN> philipl, I'm in Sweden helping at an event. The header should have precautions to be compatible with both SDK and non-sdk? [11:33:50 CET] <BtbN> That's why it passes in the functions as parameters. [11:34:19 CET] <BtbN> Going back to the old way also breaks compilation in some cases, due to a duplicated symbol. [12:33:47 CET] <nevcairiel> Not if you do it right this time [13:16:02 CET] <BtbN> How else would you do it? It had the same symbol in multiple libs, which broke in some edge cases with shared linking. [13:22:33 CET] <JEEB> IIRC he said that oyu would onyl build the common symbol source with shared builds or so [13:22:44 CET] <JEEB> somewhere in the IRC logs there was the thing mentioned [13:33:11 CET] <nevcairiel> BtbN: the same unexported ff_ symbol in multiple shared libraries should never cause problems, we do that with other symbols already. What might be a problem is having the same ff_ symbol in multiple static libraries, and you can avoid that by only cloning the object in shared builds, like with the other symbols that use this technique [13:42:00 CET] <BtbN> nevcairiel, in the old approach it was exported though. Since there is no helper macro to mark it as "Do not export" [13:42:36 CET] <BtbN> And the problem there currently is with it using symbols from ffnvcodec was there before, that part is unchanged [13:42:58 CET] <BtbN> It can be relatively easily avoided by defining the function signature on its own. [13:44:15 CET] <BtbN> git does weird things. I just pulled, and "rename libavutil/cuda_check.c => libavcodec/mips/vp3dsp_init_mips.c (50%)" [14:30:35 CET] <nevcairiel> BtbN: anythign starting with ff is automatically not exported [14:31:13 CET] <nevcairiel> or m ore precisely, anything not starting with av* [14:31:59 CET] <nevcairiel> in any case, we use the same technique for other symbols, with one key difference: in static builds its not duplicated to avoid issues [14:51:44 CET] <BtbN> Weird. I do think just having it a inline function in the header is the right way. It's pretty much a better macro anyway [16:15:44 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/f028d813709cb14bdf08de898bc560e41e… [16:16:06 CET] <philipl> That was my attempt at making it compatible with both forms. [16:20:24 CET] <BtbN> philipl, I'd say just don't use the typedefs and cast to the function type manually. [16:49:19 CET] <philipl> BtbN: In other words, have local definitions of the function signatures in the header? [16:49:25 CET] <philipl> sure. I'll try that. [17:04:43 CET] <cassidy> Hi there! I sent a patch to the mailing list but didn't get any review so far. Any chance one of you could take a look? thanks! http://ffmpeg.org/pipermail/ffmpeg-devel/2019-February/240026.html [17:26:00 CET] <JEEB> cassidy: just check if there were any tests for that format (a quick git grep for cdg should be able to figure that out) [17:26:14 CET] <JEEB> and check who's the maintainer for that module with git (gui) blame [17:27:24 CET] <JEEB> aand james replied it seems :) [17:27:59 CET] <JEEB> also that confirms that if I want to find out packets with unknown durations zero is relevant [17:31:41 CET] <nevcairiel> it sort of makes sense since a duration of 0 is basically meaningless, but it can be a bit confusing to have everything else be NOPTS but this 0 [17:33:16 CET] <cassidy> JEEB, just tried and if I set it to 0, it ends up as 1 in my application (from av_read_frame()). Not sure why [17:34:21 CET] <cassidy> while if I set to NOPTS I get it as it in my app so I can properly parse it as "no duration" [17:48:14 CET] <BtbN> philipl, either that, or no definitions at all. Would be two very ugly casts. [19:24:14 CET] <durandal_1707> anybody can capture mpeg with AC-4 audio with one of their cards ? [19:26:34 CET] <kierank> I think people in paris can [19:46:30 CET] <durandal_1707> who is in Paris? I think that only east is in AC-4 - firmwares for TV brands [19:52:03 CET] <kierank> most videolan people [19:53:30 CET] <durandal_1707> they are very silent here, are they on party? or are again on streets? [19:55:20 CET] <kierank> getting drunk on wine and cheese [19:55:38 CET] <durandal_1707> and breaking capture cards in process [19:56:23 CET] <atomnuker> have you ran out of samples? [19:56:39 CET] <JEEB> he needs to figure out the ID for MPEG-TS [19:56:45 CET] <JEEB> since it's not in the specs [19:56:49 CET] <JEEB> (unlike the mp4 one) [19:57:03 CET] <JEEB> because the dshow module that he can use to verify if his stuff is more or less correct only does MPEG-TS [19:57:13 CET] <durandal_1707> i'm too lazy to compile lavfilters to just find out that .ax file will not coperate [19:57:53 CET] <JEEB> if the structure of the MPEG-TS broadcast is being published somewhere that'd be enough as well:P (like the identifiers and such) [19:59:30 CET] <durandal_1707> ETSI standards is spreading incomplete standards as usual [20:00:24 CET] <durandal_1707> some descriptor tags are already taken, pretty much all of them [20:00:43 CET] <JEEB> yea, the stuff that's defined there is just the same that's used for other Dolby and DTS formats [20:00:54 CET] <JEEB> you have a separate registration ID somewhere that specifies that it's AC-4 [20:01:05 CET] <atomnuker> can't you just check what's in the file? if it doesn't conflict with anything it could be correct [20:01:16 CET] <durandal_1707> its probably just single byte [20:01:37 CET] <durandal_1707> atomnuker: there are no mpeg-ts known samples, only mp4 [20:01:57 CET] <JEEB> > * Add AC-4 format support in Mp4Extractor and TsExtractor [20:02:04 CET] <JEEB> https://github.com/DolbyLaboratories/ExoPlayer/commit/e462c6aab7dc5cab47c3d… [20:02:12 CET] <JEEB> so they have their own fork of ExoPlayer for it, lol [20:02:55 CET] <JEEB> > library/core/src/test/assets/ts/sample.ac4 [20:03:04 CET] <JEEB> is that a ts or raw ac4 sample [20:03:05 CET] <JEEB> lol [20:03:30 CET] <JEEB> probably raw [20:04:15 CET] <durandal_1707> JEEB: you are GENIUS [20:08:19 CET] <durandal_1707> this is raw AC-4, which is still something [20:08:26 CET] <JEEB> https://github.com/DolbyLaboratories/ExoPlayer/blob/dev-v2-ac4/library/core… [20:08:32 CET] <JEEB> this seems to be the MPEG-TS bullcrap [20:09:07 CET] <JEEB> TS_STREAM_TYPE_AC4 = 0xAC; /* DVB/ATSC AC-4 Descriptor */ and then AC4_FORMAT_IDENTIFIER = Util.getIntegerCodeForString("AC-4"); [20:09:30 CET] <JEEB> https://github.com/DolbyLaboratories/ExoPlayer/blob/dev-v2-ac4/library/core… [20:09:54 CET] <JEEB> private static final int TS_PMT_DESC_DVB_EXT_AC4 = 0x15; [20:11:17 CET] <JEEB> ok, so one thing is registration descriptor where you have probably something like "AC-4" [20:11:48 CET] <JEEB> and the other is the extension descriptor in ETSI EN 300 468 [20:12:01 CET] <JEEB> AC-4_descriptor in DVB (ETSI EN 300 468) [20:14:00 CET] <JEEB> https://www.etsi.org/deliver/etsi_en/300400_300499/300468/01.15.01_60/en_30… [20:14:03 CET] <JEEB> annex D [20:14:17 CET] <JEEB> seems to contain the AC-4 bullcrap [20:17:01 CET] <JEEB> and 6.3 "Extended descriptor identification and location" contains the 0x15 [20:17:08 CET] <JEEB> which is AC-4_descriptor [20:43:20 CET] <durandal_1707> JEEB: does AC-4 nees special private crap in mpeg-ts, unlike AC-3? [20:46:17 CET] <JEEB> it'sa custom descriptor that has to be written if you want to mux [20:46:39 CET] <JEEB> not sure if demuxers check anything else than the size [20:46:57 CET] <JEEB> then there's the stuff that mpegts.c calls REGD_types [20:47:08 CET] <JEEB> that's another way, not sure if it's AC-4 or what tho exactly [20:47:16 CET] <JEEB> probably exactly that [20:48:16 CET] <JEEB> the other ETSI spec noted how the AC-4 data packets were put into a length-first thing [20:48:32 CET] <JEEB> (just look for PES packets) [21:16:32 CET] <durandal_1707> JEEB: looks like this sample.ac4 uses bitstream version 2, which is not documented at all in specification [21:16:56 CET] <JEEB> it's in part 2 [21:16:56 CET] <JEEB> IIRC [21:17:53 CET] <JEEB> ETSI TS 103 190-2 [21:18:16 CET] <JEEB> https://www.etsi.org/deliver/etsi_ts/103100_103199/10319002/01.02.01_60/ts_… [21:19:27 CET] <JEEB> and yes, this darn spec has the MPEG-2 TS stuff [21:19:40 CET] <JEEB> registration_descriptor 0x41 0x43 0x2D 0x34 (AC-4) [21:20:05 CET] <JEEB> but primary means is the AC-4 descriptor [21:20:21 CET] <JEEB> the registration thing is a fall-back for receivers that don't understand the AC-4 specific descriptor [21:25:52 CET] <cone-287> ffmpeg 03Matthew Fearnley 07master:2d80b56ce0d4: libavcodec/zmbvenc: block scoring improvements/bug fixes [21:25:52 CET] <cone-287> ffmpeg 03Matthew Fearnley 07master:f2e89fe4d34a: libavcodec/zmbvenc: motion estimation improvements/bug fixes: [21:33:30 CET] <thardin> does FATE test encoders too? [21:34:04 CET] <JEEB> it has the capability to, yes [21:34:20 CET] <JEEB> if someone adds a test based on some input that can be generated or so [21:34:48 CET] <thardin> so I notice [21:35:04 CET] <thardin> just some codecs missing tests. looking at zmbv [21:35:04 CET] <JEEB> usually with the bitexact etc flags in case the generated input is RGB and then you need to YCbCr'ify it in the middle [21:35:09 CET] <JEEB> yea [21:35:12 CET] <JEEB> unfortunately [21:36:04 CET] <thardin> feels like something that could be automagically generated. for e in $ENCODERS ; do ffmpeg -i ref.avi -vcodec $e - | sha1sum etc etc [21:36:20 CET] <thardin> whatever that becomes in make parlance [21:36:38 CET] <JEEB> there's various per-packet checksum things [21:38:37 CET] <thardin> another thing: what's the procedure to get new samples into the fate collection? [21:38:59 CET] <JEEB> poking michaelni or so who has rights to upload, then stuff should get propagated after ~48h [21:39:06 CET] <JEEB> and then the actual tests can start getting merged [21:39:14 CET] <cone-287> ffmpeg 03Tomas Härdin 07master:abc5ac3cf517: palettegen: Fill with last color, not black [21:39:29 CET] <JEEB> note: I just don't remember all the people with fate-samples access [21:40:03 CET] <thardin> I have some codec2 samples in mind, they're tiny enough to be attached on the ML [21:41:08 CET] <JEEB> alright, that's another way of requesting them to get uploaded [21:41:46 CET] <thardin> neither encoder nor decoder at bitexact tho, so testing is somewhat limited. but being confident they decode without problems is better than nothing [21:42:46 CET] <thardin> besides remuxing, which should be bitexact [21:58:35 CET] <atomnuker> we don't test external libraries though [23:05:55 CET] <cone-287> ffmpeg 03Martin Storsjö 07master:c950beb68dee: aarch64: vp8: Fix assembling with clang [23:05:56 CET] <cone-287> ffmpeg 03Martin Storsjö 07master:7ddfa5e9083b: aarch64: vp8: Fix assembling with armasm64 [23:05:57 CET] <cone-287> ffmpeg 03Martin Storsjö 07master:fecf75a5c4f6: aarch64: vp8: Remove superfluous includes [23:05:58 CET] <cone-287> ffmpeg 03Martin Storsjö 07master:c8bc9d1380dd: aarch64: vp8: Move the vp8dsp makefile entries to the right places [00:00:00 CET] --- Wed Feb 20 2019

1 0

ffmpeg.log.20190219
by burek 20 Feb '19

20 Feb '19

[05:11:25 CET] <kepstin> giaco: if you already know what adjustment you want to make to the volume, then you can use the volume filter to apply it [05:12:04 CET] <kepstin> e.g. "this should be 3dB louder than it currently is", then use `-af volume=3dB` [05:15:06 CET] <kepstin> if you don't know what the input loudness is, and you want it normalized to a certain reference loudness, then it gets a bit more complicated. [10:52:10 CET] <andrey_utkin> Does anybody have an opinion on which terminal font looks best on a screencast video after aggressive video compression as used by Youtube etc? [14:20:54 CET] <DHE> andrey_utkin: if it's a mostly static image, the compression should still preserve a good sharp image at sufficient resolution [15:47:35 CET] <faLUCE> Hello. I compiled ffmpeg 4.x on linux but ffplay was not added. What do I have to check in ./configure ? [15:48:09 CET] <DHE> probably need SDL installed, with the -dev or -devel package [15:52:43 CET] <faLUCE> DHE: but should I add sdl in the configure of ffmpeg as well, or is it automatically checked? [16:12:48 CET] <DHE> should be automatic, but it needs to find SDL to be able to build ffplay [16:14:21 CET] <faLUCE> DHE: I see. I think it should be added an option lile "enable-ffplay" or so. Each time I have this issue, and after months I don't remember which was the trick [16:14:41 CET] <faLUCE> (when I recompile ffmpeg) [16:16:49 CET] <JEEB> then use --disable-autodetect and specifically enable sdl? [16:16:54 CET] <JEEB> s/enable/require/ [16:17:10 CET] <JEEB> which is --enable-sdl [16:17:22 CET] <faLUCE> JEEB: it would be clearer (IMHO) if there's a specific option for ffplay [16:18:44 CET] <JEEB> I think there might even be since there's an example of --disable-ffplay [16:18:54 CET] <JEEB> so the other way [16:20:33 CET] <faLUCE> disable-ffplay doesn't help in understanding that- There should be --enable-ffplay (default: NO) [16:20:42 CET] <faLUCE> and then an error if sdl is not found [16:20:52 CET] <faLUCE> this much clearer [16:21:55 CET] <JEEB> feel free to make a bug report [16:22:07 CET] <JEEB> on the trac [16:22:14 CET] <faLUCE> I'll do [17:09:23 CET] <faLUCE> I got this warning from libx264: [libx264 @ 0x5565050987c0] MB rate (1200000000) > level limit (16711680) ... which field of AvcodecContext could I set for avoiding it? I tried with ctxt->bit_rate but did not solve [17:12:52 CET] <kepstin> faLUCE: you've set a level that's incompatible with the video frame size/framerate [17:13:13 CET] <kepstin> so you either have to increase the level (or maybe just leave it unset if you don't need it), or reduce the frame size / framerate [17:14:45 CET] <kepstin> oh, wow, that's the limit for level 6.2, which should be good for 4k video at 300fps [17:15:01 CET] <kepstin> there's something wrong with some of your other parameters if that's not working :/ [17:15:41 CET] <faLUCE> kepstin: maybe gopsize? [17:15:44 CET] <kepstin> it could be that your frame timestamps or timebase are incorrect, so the encoder is seeing a much higher framerate than expected [17:17:36 CET] <faLUCE> kepstin: DEFAULT_BITRATE, GOPSIZE=10, H264_ULTRAFAST, H264_DEFAULT_PROFILE, H264_DEFAULT_TUNE [17:18:11 CET] <kepstin> the problem is not bitrate or gop size or anything in the encoder parameters [17:18:34 CET] <kepstin> the problem is that the encoder thinks the volume of pixels (well, macroblocks) it's encoding per second is too high [17:18:48 CET] <kepstin> which indicates that you likely have an issue with timestamps or timebases [17:19:20 CET] <faLUCE> I see, I have to check better [17:25:49 CET] <kepstin> an example of this sort of problem would be if you're outputting to mkv - the ffmpeg mkv muxer has a fixed timebase of 1/1000 - if you set the encoder to use the container timestamp but forgot to convert the timestamps, then the encoder might see a framerate that looks 100s of times too high. [17:53:10 CET] <faLUCE> kepstin: I used mVideoEncoderCodecContext->time_base = AV_TIME_BASE_Q; [17:53:34 CET] <faLUCE> (and ts muxer) [17:53:46 CET] <faLUCE> (mpegts) [17:53:48 CET] <kepstin> well, that's probably wrong. [17:53:59 CET] <faLUCE> why? [17:54:15 CET] <kepstin> I'd recommend setting the encoder muxer to the timebase from the container, to avoid having to do multiple conversions [17:54:36 CET] <JEEB> MPEG-TS will anyways set itself to 90k [17:54:37 CET] <kepstin> and don't forget to rescale frame timestamps to the correct timebase before sending frames to the encoder [17:54:56 CET] <JEEB> you can't expect even if you set the time base before that the muxer will actually be capable of doing that [17:55:12 CET] <JEEB> so after writing the header and initializing, just rescale [17:55:27 CET] <JEEB> according to the muxer AVStream's time base [17:55:53 CET] <kepstin> i think you might have to do a manual step to pass the muxer's time base to the encoder still? not sure [17:56:20 CET] <JEEB> you have to set the time base anyways (or at least attempt to) [17:56:45 CET] <JEEB> encoder's time base I would recommend being what you need. the conversions aren't bad anyways as long as you never skip them [17:58:57 CET] <kepstin> hmm, but if you set encoder timebase to the muxer/avstream timebase, then the dts/pts values should be good right out of the encoder - i could imagine people forgetting to scale dts and getting weird issues due to that :) [17:59:21 CET] <giaco> kepstin: late thanks for your answer [18:00:11 CET] <giaco> well, yes, my requirements wants me to amplify the processed audio on the fly, without double pass and without knowing in advance the desired change in db. Is that possible? [18:01:28 CET] <kepstin> giaco: yep. https://www.ffmpeg.org/ffmpeg-filters.html#loudnorm can operate in 1-pass mode, with a target loudness set in LUFS. [18:03:45 CET] <kepstin> giaco: for a live streaming use case, it should be as simple as setting the `I` option on that filter to the desired loudness, and sticking an aresample filter after it to convert back to a reasonable sample rate (48K or 44.1K probably) [18:06:13 CET] <faLUCE> JEEB: kepstin, so what is the appropriate time_base for h264 ? (variable frame rate) [18:06:33 CET] <JEEB> whatever is good enough for you [18:06:54 CET] <giaco> kepstin: I'd surely make a mess before getting the command line right. Would you be so gentle to drop a ffmpeg cmd considering mono PCM s16le 44100 in stdin and mp4 (or whatever) as output, same rate? [18:07:09 CET] <kepstin> faLUCE: pick something that works for you, then try setting it on the output stream (muxer), and then check what the muxer actually returned, and use that [18:07:27 CET] <kepstin> faLUCE: and *scale* to that. [18:07:55 CET] <giaco> ffmpeg -f s16le -ar 44100 -ac 1 -i pipe:0 -map 0 .... -f lame out.mp3 [18:08:45 CET] <kepstin> giaco: take your existing command line, add `-af loudnorm=I=-18,aresample=44100` [18:09:06 CET] <kepstin> replace the -18 with a value to taste (-18 is the reference level used for replaygain, fwiw) [18:09:27 CET] <giaco> kepstin: thanks [18:11:26 CET] <faLUCE> can I use a time base which is higher than the max framerate I can expect? for example: mVideoEncoderCodecContext->time_base = (AVRational){1,200}; [18:11:39 CET] <faLUCE> and then rescale the pts according to it? [18:12:49 CET] <giaco> kepstin: I'm pasting my whole cmd. It is working but I'm learning and I'm looking for any valuable suggestion from experts. Thanks [18:12:58 CET] <giaco> ffmpeg -f s16le -ar 44100 -ac 1 -i pipe:0 -map 0 -af loudnorm=I=-18,aresample=44100 -c:a libopus -b:a 64000 -vbr on -compression_level 10 -frame_duration 20 -packet_loss 0 -application audio -cutoff 0 -f dash -strict -2 stream.mpd [18:15:38 CET] <kepstin> giaco: fwiw, all of the options "-vbr on -compression_level 10 -frame_duration 20 -packet_loss 0 -application audio -cutoff 0", you're just setting them all to the default values [18:15:47 CET] <kepstin> so you might as well just remove them [18:16:33 CET] <giaco> kepstin: yes, but I'm playing with them so I prefer to leave them there waiting for some more tuning [18:16:56 CET] <kepstin> opus internally does its own sample rate handling, it doesn't preserve sample rate. the recommended input rate to the opus encoder is 48000 [18:17:10 CET] <kepstin> (so change the aresample to 48000) [18:19:18 CET] <giaco> I'd have never spotted that this fast :D thank you [18:22:40 CET] <kepstin> giaco: regarding the opus settings - the only reason to change -compression_level is if you're really cpu limited on encoding/decoding, the default is max. I recommend not touching the frame_duration option - using a value other than 20 disables some of the encoding modes. The packet_loss setting is useless with dash, since it's served over tcp and can't lose packets. [18:23:50 CET] <kepstin> the cutoff option generally shouldn't be used, the opus encoder has automatic cutoff configuration based on selected bitrate, but if you're right on the edge it might be useful as a tradeoff adjustment. [18:24:17 CET] <kepstin> recent opus can do wideband at ridiculously low bitrates, which is pretty cool :) [18:25:51 CET] <kepstin> with aac-lc encoders at low bitrate (libfdk_aac in particular), the cutoff option is often useful because the default is kinda low; depending on audio content you might prefer the artifacts of a higher cutoff vs the muddiness of a lower cutoff. [18:26:47 CET] <giaco> I'm very impressed by opus performance [18:27:12 CET] <giaco> I've been fighting to it for this application [18:27:29 CET] <giaco> I know that opus in dash is experimental, but it works to me [18:31:11 CET] <faLUCE> kepstin: from what I see, it should be useless to set a timebase for a variable frame rate, on the encoder. But ffmpeg wants it in each case. So I set it as AVRATIONAL {1,12} . And the problem disappeared [18:32:09 CET] <kepstin> faLUCE: the encoder needs to know the timebase that the input frames are on if you want to use any bitrate controls [18:32:32 CET] <kepstin> how can it know how many bits to allocate per frame if it doesn't know how many frames were in any given second? [18:33:03 CET] <faLUCE> kepstin: it can now it if I set ctxt->bit_rate [18:33:52 CET] <kepstin> faLUCE: that's "bits per second". so how does the encoder go from that value to "bits per frame" unless it knows how long each frame is? [18:34:29 CET] <kepstin> faLUCE: you should set the timebase on the encoder to the same timebase that the frames your sending to the encoder have pts set relative to [18:34:33 CET] <kepstin> then everything will work [18:35:18 CET] <faLUCE> kepstin: given that I don't know the framerate, I set it to AVRATIONAL{1,100), which corresponds to a high framerate [18:35:34 CET] <kepstin> faLUCE: timebase has nothing to do with framerate [18:36:12 CET] <kepstin> faLUCE: you set timebase to a value such that pts * time_base = time_when_frame_displays_in_seconds [18:37:51 CET] <kepstin> so if your frames have pts values "1, 30, 600", and your timebase is 1/5000, then your frames will be displayed at 0.002s, 0.06s, and 1.2s [18:38:02 CET] <kepstin> er, timebase is 1/500 for that example [18:38:02 CET] <faLUCE> kepstin: I set the pts, for each frame, in this way: dateTimeNow.tv_sec * 1000000000 + dateTimeNow.tv_nsec; [18:38:31 CET] <kepstin> faLUCE: ok, then your timebase is 1/1000000000 [18:38:45 CET] <faLUCE> kepstin: this is AV_RATIONAL_Q [18:38:52 CET] <faLUCE> but it's too high for H264 [18:39:56 CET] <kepstin> you mean AV_TIME_BASE_Q? [18:40:02 CET] <faLUCE> kepstin: yes, sorry [18:40:33 CET] <faLUCE> (anyway, it doesn't matter... its' a timebase for the h264 encoder, not for the muxer) [18:40:36 CET] <kepstin> that should be fine, check to make sure that the frames have the pts values you expect [18:41:07 CET] <faLUCE> kepstin: if I set AV_TIME_BASE_Q I got the warning before I produce frames [18:41:17 CET] <kepstin> what warning? [18:41:18 CET] <faLUCE> I got it soon after allocating the codec context [18:41:57 CET] <faLUCE> [libx264 @ 0x5565050987c0] MB rate (1200000000) > level limit (16711680) [18:42:26 CET] <kepstin> that's printed before you try encoding any frames? [18:42:42 CET] <faLUCE> kepstin: yes [18:42:55 CET] <faLUCE> kepstin: note that I can encode, stream and mux all correctly [18:43:07 CET] <faLUCE> but I want to avoid this strange warning [18:43:45 CET] <faLUCE> kepstin: all the timestamps are ok. as you saw, I compute them with date time and use AVRATIONAL_Q [18:44:11 CET] <kepstin> hmm. [18:44:13 CET] <faLUCE> but it seems that x264 doesn't want this resolution [18:44:23 CET] Action: kepstin checks the x264 adapter code to see if there's anything obvious [18:44:53 CET] <faLUCE> kepstin: maybe I could scale by 10 or 100 both the timebase and the pts [18:45:00 CET] <faLUCE> so to avoid this warning [18:45:27 CET] <kepstin> I normally recommend setting the encoder timebase to the value from the muxer, and then rescaling to that before sending frames to the encoder. [18:45:50 CET] <kepstin> which would likely also work around this issue, if the problem is just that the timebase is too big for some precision inside x264 [18:46:02 CET] <faLUCE> kepstin: I use multiple muxers [18:46:20 CET] <faLUCE> then I though about scaling both AV_TIMEBASE_Q and timestamps [18:46:25 CET] <kepstin> ah, encode once, then mux multiple times? that would be a pain then [18:46:31 CET] <faLUCE> (thought) [18:46:57 CET] <faLUCE> it's not a pain, I use a different timebases for each muxer [18:47:19 CET] <kepstin> well, it means you don't have a single common timebase for all muxers [18:47:26 CET] <faLUCE> exactly [18:47:38 CET] <faLUCE> in fact the encoder's timebase is not strictly necessary [18:47:54 CET] <faLUCE> but it could be useful if I record raw h264 [18:48:00 CET] <kepstin> hmm. so the libx264 wrapper sets the "fps" config on the x264 encoder to (time_base.den / time_base.num * avctx->ticks_per_frame) [18:48:08 CET] <kepstin> that's probably what's causing the message [18:48:29 CET] <faLUCE> kepstin: [17:28] <BugMaster|work> also you may need to set "ticks_per_frame" [18:49:03 CET] <faLUCE> but what do I have to set for "ticks_per_frame" ? [18:49:09 CET] <kepstin> yeah, setting ticks_per_frame based on an estimate - even a wild guess - of the framerate would probably be good enough [18:49:45 CET] <faLUCE> kepstin: I don't know the framerate... it's variable [18:50:17 CET] <faLUCE> kepstin: note that I did not have this warning on the previous version of ffmpeg or x264 [18:51:53 CET] <kepstin> this warning is printed inside x264 - all its saying is that "given the framerate you've told me as cfr, the amount of data being encoded would be too high for the selected level" [18:52:12 CET] <faLUCE> kepstin: then I have to set vbr in some way [18:53:14 CET] <kepstin> so yeah, in your case I guess you could just ignore it. Alternately set the ticks_per_frame value to something that you expect the input probably won't exceed, or reduce the timebase (you don't really need nanosecond accuracy anyways, no container can store that) [18:53:45 CET] <kepstin> the only thing setting ticks_per_frame here would do is supress this warning, it shouldn't have any effect on the actual encoded video. [18:54:17 CET] <faLUCE> kepstin: reading the API, about ticks_per_frame: "Set to time_base ticks per frame. Default 1, e.g., H.264/MPEG-2 set it to 2." [18:54:50 CET] <faLUCE> but the problem is that x264 believes it's cfr, while it's vbr [18:56:08 CET] <kepstin> x264 defaults to vfr input, ffmpeg only overrides that to cfr mode if you enable the bluray compat option [18:56:32 CET] <faLUCE> then why it thinks it's cfr ? [18:56:43 CET] <kepstin> the input is working fine, the only issue is the warning about the level, which appears to be based only on what the input framerate is set to [18:56:56 CET] <kepstin> so yeah, just ignore the warning. [18:57:06 CET] <faLUCE> do you think it's a bug? [18:57:21 CET] <faLUCE> I did not set any framerate [18:57:40 CET] <kepstin> not really - you haven't set a framerate, so it can't possibly calculate a meaningful value there. ffmpeg guess makes a guess based on timebase, really. [18:58:09 CET] <faLUCE> so, a workaround could be setting a high framerate... [18:58:19 CET] <faLUCE> ? [18:58:37 CET] <faLUCE> (I don't like this warning, I want to clear it) [18:58:53 CET] <kepstin> a workaround could be setting the ticks_per_frame to something so that the i_fps values sent to x264 are something reasonable, then it won't show the warning. [18:59:58 CET] <faLUCE> kepstin: this->mVideoEncoderCodecContext->ticks_per_frame = 100; it works but I don't understand if 100 is reasonable [19:00:39 CET] <faLUCE> what if I change the encoder's params? (profile, tune etc) [19:01:46 CET] <faLUCE> another workaround is setting the timebase to a lower resolution [19:01:55 CET] <faLUCE> (maybe) [19:02:19 CET] <kepstin> the ticks per frame is basically saying "one frame is ticks_per_frame * time_base long" (or alternately, "the framerate is 1/ (ticks_per_frame * time_base") [19:02:52 CET] <kepstin> i wonder if there's a way to just disable the level checking completely in x264 [19:03:55 CET] <faLUCE> from what I see this is stuff concerning cfr [19:03:59 CET] <faLUCE> not vbr [19:04:08 CET] <kepstin> faLUCE: anywayse, the warning itself is meaningless for your usecase, and can be ignored. The whole levels concept makes no sense unless your content is cfr (or at least has a known maximum framerate) [19:04:28 CET] <faLUCE> I know it's meaningless, but I want to remove it [19:04:42 CET] <kepstin> if you have a known maximum framerate, then just calculate a ticks_per_frame based on that, and you're done. [19:04:44 CET] <faLUCE> it's annoying to view it while running my library [19:05:00 CET] <faLUCE> maximum framerate is 100 [19:06:02 CET] <kepstin> if you know a max framerate, then set ticks_per frame to 1/(maxrate*time_base) [19:06:29 CET] <faLUCE> time_base is expressed as AV_TIMEBASE_Q [19:06:50 CET] <faLUCE> then 1/(100 * ...? ) [19:06:53 CET] <kepstin> equivalently, with integer math, ticks_per_frame = time_base.den / max_framerate [19:07:01 CET] <faLUCE> ok thanks [19:07:04 CET] <faLUCE> let's try [19:07:10 CET] <kepstin> and add a * time_base.num on the end in case that's ever a value other than 1 [19:07:19 CET] <kepstin> which is unlikely in your use case, but still [19:11:22 CET] <kepstin> hmm. not sure if I got that quite right, maybe that should be a /time_base.num at the end - need to check the math there :0 [19:11:57 CET] <kepstin> (pretty much the only time you see a time base numerator other than 1 is when dealing with ntsc cfr content, where the numerator is 1001) [19:12:45 CET] <faLUCE> kepstin: with your previous formula I obtained ticks_per_frame = 10000 [19:16:13 CET] <kepstin> `ticks_per_frame = time_base.den / max_frame_rate / time_base.num` is the correct formula [19:16:31 CET] <kepstin> (you'll still get 10000 with AV_TIME_BASE_Q) [19:16:44 CET] <faLUCE> yes [19:17:12 CET] <faLUCE> anyway, thanks for all (btw: what a pain for a so strange warning...) [19:17:39 CET] <faLUCE> I think this is a bug [19:19:00 CET] <kepstin> kind of a tricky bug, if so. x264 can't print this warning unless it knows the expected framerate in advance, and in full vfr mode, ffmpeg doesn't have any field with the expected frame rate stored. [19:19:15 CET] <kepstin> x264 can't print the warning correctly* [19:19:25 CET] <faLUCE> I agree [19:19:51 CET] <faLUCE> but I think that the default for x264 is cfr [19:20:00 CET] <faLUCE> so it seems a ffmpeg bug [19:20:03 CET] <kepstin> no, it correctly defaults to vfr input [19:20:18 CET] <faLUCE> uhmmmm [19:20:39 CET] <kepstin> ffmpeg is setting the "expected framerate" that x264 uses to check level limits based on the timebase, since it doesn't have any better value available for vfr stuff. [19:20:52 CET] <kepstin> but the actual video encoding and rate control is all correctly vfr [19:21:08 CET] <kepstin> the warning does nothing except tell you that x264 couldn't verify the level [19:21:33 CET] <faLUCE> no, the warning says that it's uncorrect level [19:21:47 CET] <faLUCE> maybe x264 people should change the msg? [19:23:28 CET] <faLUCE> now, closed this issue, is there an #ifdef which I can use in order to check if the library's version is > than 4.x ? [19:23:30 CET] <kepstin> it doesn't say incorrect level anywhere? Just that one of the parameters of the input video would exceed the limit that the selected level has [19:24:19 CET] <faLUCE> coming back in 15 mins [19:29:05 CET] <kepstin> hmm. i think this can be improved in the ffmpeg side, actually. The x264 wrapper could check the `framerate` field on the encoder context, and if it's set to the special value 0/1 which is used to explicitly indicate vfr, then it can set the x264 i_fps fields to 0, which will disable this limit check. [19:31:35 CET] <kepstin> https://git.videolan.org/?p=x264.git;a=blob;f=encoder/set.c;h=07a1261e180d0… appears to be where this warning is printed [19:33:18 CET] <kepstin> that's not a typical or documented usage of the framerate field, but it could work for this use case. [20:22:35 CET] <kepstin> oh, never mind, that doesn't work. setting i_fps to blank values means x264 will use the default of 25fps internally [21:24:37 CET] <Abbott> I am getting "Automatic encoder selection failed for output stream #0:0. Default encoder for format mp3 (codec png) is probably disabled. Please choose an encoder manually." but didn't I manually specify an encoder with -c:a libmp3lame if that was in my command? [21:26:09 CET] <Abbott> Stream #0:0: Audio: flac, 44100 Hz, stereo, s16, in this case [21:28:16 CET] <JEEB> Abbott: you should probably pastebin the full log but I kind of expect the thing to be the album art or so [21:35:55 CET] <Abbott> okay, one sec [21:39:55 CET] <Abbott> JEEB: http://dpaste.com/1V8JNVD.txt [21:40:16 CET] <JEEB> yup [21:40:43 CET] <JEEB> it's trying to push the JPEG from the flac into the mp3 [21:41:32 CET] <Abbott> How would I tell it to strip the embedded album art? [21:42:59 CET] <JEEB> there was an option for that but I don't remember it exactly [21:43:13 CET] <furq> -vn [21:43:35 CET] <JEEB> well yes, that's one way [21:43:42 CET] <JEEB> that just disables video in output [21:51:00 CET] <Abbott> sweet, -vn seems to do it. I encoded a lot of music with a find ... -exec ffmpeg .... command, so will adding -n be a good way to ensure I don't re-encode stuff I already did? Or is that not how -n works [21:51:44 CET] <JEEB> no, it's not that [21:53:37 CET] <Abbott> so the files that failed because of the embedded artwork didn't get outputted to the dest directory, but the ones that didn't have artwork did. -n says "don't overwrite dest file if it exists," so wouldn't that mean it would skip over files that have already encoded? [21:55:55 CET] <JEEB> ok, there was an alternative to -y? [21:55:57 CET] <JEEB> then maybe [21:56:05 CET] <JEEB> I thought you were gathering something out of -vn towards just -n [21:58:24 CET] <Abbott> oh, no. I just stumbled upon -n the other day on accident cause i was looking for something like a --dry-run flag (I since found -f null) [21:58:30 CET] <Abbott> but now I figure it's good for this application [22:03:49 CET] <Hello71> I think -n also returns non-zero if the output exists [22:04:13 CET] <JEEB> quite likely [00:00:00 CET] --- Wed Feb 20 2019

1 0

ffmpeg-devel.log.20190218
by burek 19 Feb '19

19 Feb '19

[21:17:10 CET] <thebombzen> are cuGetErrorName and cuGetErrorString on line 38 of libavutil/cuda_check.h *supposed* to start with a 't'? cause removing the 't' causes a compile error to go away [21:34:25 CET] <jdarnley> Some API mismatch? [21:57:38 CET] <philipl> thebombzen: Read back the history [21:57:47 CET] <philipl> It's a problem with the code as checked in today. [21:58:00 CET] <philipl> filters that directly use the cuda sdk fail to compile. [21:58:17 CET] <philipl> This is one possible fix: https://github.com/philipl/FFmpeg/commit/f028d813709cb14bdf08de898bc560e41e… [21:58:26 CET] <philipl> BtbN is away and hasn't commented yet. [21:59:48 CET] <philipl> Another alternative is to go back to cuda_check.c as a compiled file and be intelligent about not compiling it in multiple times when doing static builds. [23:46:55 CET] <cone-990> ffmpeg 03Xiaofeng Wang 07master:821791caa065: lavf/mpeg: fix indent [00:00:00 CET] --- Tue Feb 19 2019

1 0

ffmpeg.log.20190218
by burek 19 Feb '19

19 Feb '19

[04:11:59 CET] <FurretUber> I'm trying to generate a visualization and encode it using VAAPI, but I'm not finding how to make the command work. The command is: ffmpeg -vaapi_device /dev/dri/renderD128 -i snd.wav -filter_complex "[0:a]extrastereo=m=0,showwaves=s=800x450:mode=p2p:r=30:colors=white|white[vid],format=nv12,hwupload" -map "[vid]" -map 0:a -acodec copy -threads 4 -vcodec h264_vaapi -low_power 1 -r 30 -f nut - and the output is: https://termbin.com/ha20 [04:14:25 CET] <FurretUber> Doing this generating the visualization encoded with rawvideo and piped to vaapi encode works but is too expensive [04:27:43 CET] <FurretUber> I found where to insert the VAAPI filters, the correct command line is: ffmpeg -vaapi_device /dev/dri/renderD128 -i snd.wav -filter_complex "[0:a]extrastereo=m=0,showwaves=s=800x450:mode=p2p:r=30:colors=white|white,format=nv12,hwupload[vid]" -map "[vid]" -map 0:a -acodec copy -vcodec h264_vaapi -low_power 1 -r 30 -f nut - . Many iterations were required until finding the right place [10:17:59 CET] <DimasSup> Hello! [10:20:06 CET] <DimasSup> Can any one help me with build ffmpeg for android on macos? i have build script like https://pastebin.com/74GBUZk6, but when i run this script i got error Android/sdk/ndk-bundle/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-gcc is unable to create an executable file. [10:20:06 CET] <DimasSup> C compiler test failed. [10:24:05 CET] <JEEB> ffbuild/config.log contains the failure [10:24:20 CET] <JEEB> I've built for android just fine and I've moved to the included clang quite some time ago [10:24:31 CET] <JEEB> (I think the gcc thing at this point is a wrapper that points towards clang) [10:25:58 CET] <JEEB> so for 32bit ARM I do `--arch=armv7 --cpu=armv7-a --enable-cross-compile --target-os=android --cross-prefix=arm-linux-androideabi- --cc=arm-linux-androideabi-clang --cxx=arm-linux-androideabi-clang++` [10:26:04 CET] <JEEB> you can also take a look at FATE [10:26:08 CET] <JEEB> it IIRC has NDK builds as well [10:28:31 CET] <JEEB> http://fate.ffmpeg.org/report.cgi?time=20190217183217&slot=armv8-linux-clan… [10:28:39 CET] <JEEB> although I see at least one recent aarch64 build failing [10:45:04 CET] <DimasSup> sorry for my stupd questions, i just starting with ffmpeg. [10:45:37 CET] <DimasSup> i tried change to clang but same error about not found. list in toolchains for platform are [10:45:40 CET] <DimasSup> aarch64-linux-android-addr2line aarch64-linux-android-c++filt aarch64-linux-android-gprof aarch64-linux-android-ld.gold aarch64-linux-android-objdump aarch64-linux-android-size [10:45:40 CET] <DimasSup> aarch64-linux-android-ar aarch64-linux-android-dwp aarch64-linux-android-ld aarch64-linux-android-nm aarch64-linux-android-ranlib aarch64-linux-android-strings [10:45:41 CET] <DimasSup> aarch64-linux-android-as aarch64-linux-android-elfedit aarch64-linux-android-ld.bfd aarch64-linux-android-objcopy aarch64-linux-android-readelf aarch64-linux-android-strip [10:45:57 CET] <DimasSup> there are not 'clang' and 'gcc' [10:46:23 CET] <JEEB> ok, then you aren't looking in the correct place [10:46:35 CET] <JEEB> use the standalone toolchain script to make it clear where things are :P [10:46:45 CET] <JEEB> (even though with the newer NDKs those don't really do anything) [10:46:59 CET] <JEEB> google "ndk standalone toolchain script" [10:47:03 CET] <JEEB> it comes with the NDK [10:50:05 CET] <DimasSup> thank you, i will google it [10:57:36 CET] <DimasSup> about place where i looking are 'Android/sdk/ndk-bundle/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/' [11:00:03 CET] <Mavrik> JEEB: standalone toolchain was removed in latest NDK :) [11:01:13 CET] <Mavrik> DimasSup: binaries are in toolchains/llvm/... [11:01:19 CET] <Mavrik> not toolchains/aarch64.. [11:01:56 CET] <JEEB> Mavrik: it is effectively non-op now, yes [11:02:09 CET] <JEEB> so it mostly just copies stuff in a simple manner now [11:02:16 CET] <JEEB> mostly to just make the person look into the right dir :P [11:02:25 CET] <Mavrik> ah, I thought even the .sh was removed [11:02:27 CET] <JEEB> as in, make him create the sysroot and make him look into that [11:02:32 CET] <JEEB> ah yes, sh mighthave been removed [11:02:35 CET] <JEEB> python script is still there [11:02:42 CET] <JEEB> the python script is what I meant [12:01:21 CET] <zetheroo> Can ffmpeg repair video files? [12:40:22 CET] <zetheroo> I am trying to convert a file but am getting this output: openmpt_module_create_from_memory2: ERROR: error loading file [14:39:12 CET] <DHE> zetheroo: repairing video files isn't officially something ffmpeg does. it might work, it might not. simple things like a corrupted seek index are probably easily repaired by remuxing. anything more serious might not be. [15:39:18 CET] <^T> cut a files beggining of? mp3 -> mp3 ? i tried the -ss <TIMEINSECONDS> but that kept the beggining instead of cutting it [15:44:32 CET] <c_14> ffmpeg -ss <time> -i file -c copy out.mp3 [15:54:09 CET] <^T> thanks [18:09:01 CET] <giaco> hello [18:11:21 CET] <giaco> what is the correct way to ask ffmpeg to exit cleanly? SIGINT or SIGTERM? I am trasforming a stream to dash, everything works but I am killing ffmpeg with SIGTERM when the stream ends and .tmp files are left behind. I'd like to ask ffmpeg to exit cleanly (so that it closes stream.mpd, that's the most important thing). Thank you [18:12:27 CET] <giaco> I am asking before trying because I am launching & doing the piping from within a java virtual machine and is not so linear to send a signal like sigint from there [18:19:17 CET] <bruce-> I use the ProcessBuilder and to stop I close the stream and use waitFor() on the process [18:20:31 CET] <JEEB> giaco: whatever ctrl+C gives does lead to an OK exit at least [18:20:48 CET] <JEEB> try with mp4 output and with something like libx264 where you have a queue of frames in your encoder [18:21:03 CET] <giaco> bruce-: you just close the stream without calling process.destory()? That should be sigterm [18:21:20 CET] <giaco> JEEB: ctrl-c is sigint [18:21:28 CET] <giaco> in most terminals [18:25:43 CET] <giaco> bruce-: you're right, I just had to comment out the process.destroy() call. Ffmpeg is quitting nicely when the input stream is closed. Thank you [18:28:18 CET] <pagios> hi, maybe it is a silly question but is there any adaptive bitrating for the publishing side, like the ABR for viewwing side? For example to avoid dropped frames when publishing using rtmp and just lowering the quality [18:32:20 CET] <giaco> I have another question, a noob one but please be patient. I'd like to amplify the input stream before writing the output dash, I'm reading the ffmpeg wiki page but this phrase confuses me "Note that the volume filter only adjusts the volume. It does not set the volume. To set or otherwise normalize the volume of a stream, see the sections below." [00:00:00 CET] --- Tue Feb 19 2019

1 0