Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

May 2019

1 participants
61 discussions

ffmpeg-devel.log.20190530
by burek 31 May '19

31 May '19

[00:33:53 CEST] <mkver> Does anybody know a system where an attempted read via AV_RNxxA (xx = 32 or 64) at a nonaligned position actually crashes? [00:35:47 CEST] <mkver> I'm asking because I improved (so I think) the search for 0x00 0x00 0x01 startcodes. [00:36:24 CEST] <mkver> In particular, I added an implementation that does not require HAVE_FAST_UNALIGNED. [00:37:02 CEST] <mkver> It uses aligned reads and I want to make sure that the way I establish alignment works fine. [00:37:19 CEST] <mkver> Because I have no system to test this on. [00:37:33 CEST] <nevcairiel> ARM has issues with that [00:37:44 CEST] <mkver> If anybody is interested: You can find the commits here: https://github.com/mkver/FFmpeg/commits/start_3 [00:38:07 CEST] <mkver> I unfortunately have only an X64 to test this on. Could you test this? [00:38:35 CEST] <mkver> Notice that ARM has a different implementation of the startcode-search function alltogether. [00:39:33 CEST] <Lynne> I think the issue with alignment on arm was that it was just slow, and that was just on older processors [00:39:55 CEST] <nevcairiel> There is definitely systems were using RNxxA on unaligned data fails [00:40:03 CEST] <nevcairiel> we had some FATE failures not too long ago due to that [00:40:14 CEST] <mkver> The ARM-specific function would need to be disabled (in libavcodec/arm/h264dsp_init_arm.c and libavcodec/arm/vc1dsp_init_arm.c). [00:40:43 CEST] <Lynne> was it the compiler's fault? I think on such systems gcc handled paging wrt reads and writes [00:42:16 CEST] <mkver> Good to hear of these failures. Could someone tests these patches on ARM (or other hardware with slow (or none) unaligned access)? [00:42:38 CEST] <nevcairiel> I don't think the compiler can know if a pointer is necessarily going to be misaligned if you just cast a byte pointer to 32-bit or 64-bit types [00:43:16 CEST] <nevcairiel> which is what the RN32A macro does, for example [00:44:07 CEST] <mkver> I don't just cast a byte pointer to 32 or 64 bit types. [00:44:23 CEST] <nevcairiel> well if you use RNxxA, it'll do that for you :D [00:44:44 CEST] <mkver> My way of aligning a pointer is ((const uint8_t *)((uintptr_t)(buf + (mod) - 1) / (mod) * (mod))), where mod = 4 or 8. [00:45:08 CEST] <mkver> The resulting pointer is then used in RNxxA [00:45:59 CEST] <nevcairiel> fast_unaligned is really enabled on all systems that really matter, anyhow [01:07:09 CEST] <jkqxz> 32-bit ARM can be configured to SIGBUS on unaligned access. [01:07:53 CEST] <jkqxz> By default on Linux it traps to the kernel which fixes up the result (which is painfully slow if you do it much), but there is a setting to change that. [01:08:08 CEST] <jkqxz> What test would you want to run? [01:28:04 CEST] <mkver> Apply the patches in the linked branch and simply run ffmpeg -i <some H.264 elementary stream> -c copy -f null - and check whether you get the SIGBUS error. [01:28:35 CEST] <mkver> And maybe change -f null - with a framehash muxer and compare the result to the current git head. [01:29:56 CEST] <mkver> (And remember to deactivate the ARM-specific startcode function in libavcodec/arm/h264dsp_init_arm.c.) [01:33:09 CEST] <nevcairiel> so if arm32 has an ASM variant, and arm64 and x86 have fast_unaligned, what systems is that for? :D [01:34:05 CEST] <mkver> I don't know. Maybe mips? [01:34:23 CEST] <nevcairiel> I suppose so, but seems like a lot of work without a known target :) [01:34:29 CEST] <mkver> I thought that I could optimize it, so I did. [01:36:06 CEST] <jkqxz> Can you give me a clean single patch? [01:41:26 CEST] <mkver> Sent you an email. [01:43:03 CEST] <jamrial> mkver: you may instead want to look at the startcode stuff in ff_h2645_extract_rbsp(), h2645_parse.c [01:43:05 CEST] <jkqxz> Got it, thank you! That's much easier than fighting with github. [01:43:12 CEST] <jamrial> that one is run on every target [01:43:51 CEST] <mkver> I have already looked at the startcode stuff in h2645_parse.c [01:44:33 CEST] <mkver> Improving it (and cbs_h2645_assemble_fragment) is on my to-do list. [01:44:38 CEST] <jamrial> jkqxz: in case you didn't know, when looking at a github commit, if you add .patch at the end of the url it will give you a git format-patch style patch [01:45:58 CEST] <mkver> h2645_parse.c uses a suboptimal pattern. It could filter out more false positives without any extra cost. [01:48:09 CEST] <mkver> And of course, h2645_parse.c could do better if unaligned is slow :) [02:13:14 CEST] <mkver> Good night! [02:13:36 CEST] <jkqxz> Hmm. This CPU seems to be magically fixing up 4-byte reads/writes. [02:13:48 CEST] <jkqxz> Oh, too late. [02:14:07 CEST] <jkqxz> But I can get it to fail with 8-byte ones. [10:53:42 CEST] <cone-233> ffmpeg 03Linjie Fu 07master:6895b350c31d: lavf/qsvvpp: avoid the double-free when working in sys memory mode [11:40:24 CEST] <jkqxz> mkver: Turns out that CPU fixes up most 4-byte unaligned accesses automatically. (8-byte unaligned accesses do trap as expected.) [11:40:38 CEST] <jkqxz> So while there were no problems, I don't think it tested what you wanted it to test. [11:49:04 CEST] <mkver> Ok. [11:49:23 CEST] <mkver> And the framehash output showed no problems? [12:49:42 CEST] <vel0city> how do you guys get the Message-Id of an email you want to reply to in Gmail? [12:50:20 CEST] <vel0city> I'm using an extension but it seems to not be working well [12:51:34 CEST] <vel0city> I tried to send a reply via --in-reply-to and it went to a completely different one, for a different patchset [12:52:52 CEST] <vel0city> I'm using this extension: https://chrome.google.com/webstore/detail/gmail-message-id-finder/comcoiiif… [12:53:35 CEST] <JEEB> vel0city: when you open an e-mail there's the three dots on teh right at the top [12:53:44 CEST] <JEEB> "show original" is one of the alternatives [12:54:01 CEST] <JEEB> and the first value that view shows is teh Message ID [12:55:09 CEST] <vel0city> ah right, in that case, it's the same that the extension gave me [12:55:18 CEST] <vel0city> something else must be wrong [12:55:55 CEST] <vel0city> (more likely, _I'm_ doing something wrong) [12:56:20 CEST] <vel0city> though I remember in-reply-to worked fine a few months ago [19:38:54 CEST] <cone-100> ffmpeg 03Nick Renieris 07master:a7e018b05e0e: avcodec/tiff: Option to decode embedded thumbnail [19:38:54 CEST] <cone-100> ffmpeg 03Nick Renieris 07master:661facb8a89a: libavcodec/tiff: Process SubIFDs tag with multiple entries [19:38:54 CEST] <cone-100> ffmpeg 03Nick Renieris 07master:9c35285aea84: avcodec/tiff: Recognize DNG/CinemaDNG images [20:31:39 CEST] <mjbshaw> I'm looking into fixing https://trac.ffmpeg.org/ticket/6841 but there are a few ways to go about it... [20:32:10 CEST] <mjbshaw> I've got a patch that modifies the mkv muxer and makes it lie about the output stream's time_base (so it uses the audio's sample_rate instead of the "real" time base). [20:32:37 CEST] <mjbshaw> And then in mkv_write_flush_packet it rescale's the packet's timing info to be in the "real" time base. [20:32:51 CEST] <mjbshaw> It works, but like I said, it's lying. [20:33:48 CEST] <mjbshaw> Alternatively, the issue could be fixed by changing ffmpeg.c so it rescale's the packet's timing info *after* applying the avoid_negative_ts hack rather than before it. [20:34:45 CEST] <mjbshaw> While that seems more correct, it requires mucking with some of the bowels of the processing graph, and I'm not sure I have the time to do that. [20:35:37 CEST] <mjbshaw> Does anyone have any brighter ideas? [20:46:34 CEST] <mkver> I have been thinking about this ticket and ticket 7182 myself. [20:49:27 CEST] <mkver> First, what does this have to do with ffmpeg.c? The avoid_negative_ts option is not specific to ffmpeg.c, but to libavformat in general. [20:49:38 CEST] <mkver> A fix should be in the libraries. [20:53:40 CEST] <mjbshaw> ffmpeg.c line 952 rescale's the packet's ts from 1/48000 to 1/1000. [20:53:50 CEST] <mjbshaw> Which is where the rounding error is introduced. [20:54:04 CEST] <mkver> Second, for opus in Matroska there avoid_negative_ts should actually not come into play at all. [20:54:17 CEST] <mkver> the, not there [20:56:11 CEST] <mkver> After all, the Matroska file format has the ability to signal encoder delay at the container level without offsetting the actual timestamps. [20:58:18 CEST] <mjbshaw> Yeah, it's not clear to my why the mkv muxer defaults to avoid_negative_ts=1. [20:58:29 CEST] <mkver> So the generic code (in mux.c) should be changed so that it doesn't offset all the tracks just because an opus track has an initial timestamp of -6.5ms. [20:59:16 CEST] <mkver> It defaults to avoid_negative_ts because the Matroska file format can't adequatly represent negative timestamps. [20:59:47 CEST] <mkver> The CodecDelay field is only there for encoder delay, not for general timestamp shifting. [21:00:06 CEST] <mjbshaw> Oh yeah, I forgot Cluster.Timestamp is unsigned, not signed. [21:00:23 CEST] <Lynne> is the problem rounding to ms precision? matroska does allow you to change the timebase, but the muxer would probably have to be rewritten to support that [21:00:40 CEST] <mjbshaw> I've got a patch to support changing the time base of the mkv muxer. [21:00:59 CEST] <mjbshaw> https://patchwork.ffmpeg.org/patch/1959/ [21:02:02 CEST] <mjbshaw> But yeah, the problem is caused by a rounding error. mkv defaults to a timebase of 1/1000 (and is required by webm). I don't think using a more precise time base is sufficient. [21:02:53 CEST] <durandal_1707> why? [21:02:56 CEST] <mkver> Supporting more timebases in the Matroska muxer is fine, but the timestamps that should actually be written for opus can actually be represented in the default ms timebase. [21:03:44 CEST] <mkver> A more precise timebase would be sufficient (for Matroska, not for WebM, for which it is impossible), but it is not necessary. [21:03:46 CEST] <mjbshaw> durandal_1707: because (1) it doesn't work for WebM and (2) it only pushes the rounding error down to a lower-order bit; it doesn't actually fix the rounding. [21:04:30 CEST] <mkver> After all, the timestamps 0ms, 20ms, 40ms (which are the timestamps the blocks should have (before taking CodecDelay into account)) can be represented in the ms timebase. [21:05:08 CEST] <mjbshaw> Assuming you're using 20ms Opus frames, yes. But Opus frames can be 2.5ms. [21:06:26 CEST] <mkver> Yeah. For such streams, you really should use a finer timebase (if you don't want the jitter). [21:06:38 CEST] <mjbshaw> But you can't for WebM. [21:07:06 CEST] <mjbshaw> It won't be perfect, granted, but we could at least be a *little* more accurate. [21:07:51 CEST] <mjbshaw> Anyway, I agree with your earlier point that we shouldn't be shifting the time stamps of all the streams just because of Opus's delay (which is already signaled in the container). [21:08:54 CEST] <mkver> Yeah. [21:09:33 CEST] <mkver> One solution would be to use different PTS and DTS to account for encoder delay for audio. [21:10:01 CEST] <mkver> But the assumption that pts=dts for audio is so deeply ingrained into FFmpeg that this is probably a pipe dream. [21:11:00 CEST] <nevcairiel> its also not accurate, since that delayed audio isn't just offset in time, but will actually disappear [21:12:13 CEST] <mkver> Thinking about this a second time, it wouldn't work. [21:15:24 CEST] <mkver> The problem of offsetting all tracks just because one seems to have a negative initial timestamp could be solved by a new flag that signals whether a muxer has the capability to signal an encoder delay by itself. [21:16:13 CEST] <nevcairiel> You would have to verify that the signaled delay also matches the negative timestamp, of course, but that sounds sensible otherwise [21:16:51 CEST] <mjbshaw> That sounds good to me. [21:17:47 CEST] <nevcairiel> dont we already have a variety of modes for avoid_negative_ts? maybe that can just fit in there [21:17:49 CEST] <mkver> Or more precisely: In mux.c, for a muxer for which said flag is set, the timestamp to look at and check for whether it is >= 0 is not the pts, but rather pts + time of the encoder delay (given by initial_padding). [21:18:11 CEST] <mkver> There is already a avoid_negative_ts_use_pts which is only used for Matroska. [21:18:19 CEST] <mjbshaw> I was just going to mention avoid_negative_ts_use_pts. [21:18:24 CEST] <mkver> So it could be reused for this. [21:18:55 CEST] <mkver> This would solve one of the four problems currently existing with CodecDelay. [21:19:08 CEST] <mjbshaw> What are the other three problems? [21:20:03 CEST] <mkver> 1. #7182: The Matroska muxer writes the CodecDelay flag, but doesn't actually modify the timestamps. [21:21:08 CEST] <mkver> This means that a track for which the CodecDelay field is nonzero gets offset compared to tracks for which it is not (or for which it has a different value). [21:21:27 CEST] <mkver> 2. The rounding issue in the Matroska muxer. [21:22:52 CEST] <mkver> 3. The rounding issue in the Matroska demuxer: The demuxer will correctly (sample-accurately, not ns-accurately) export the CodecDelay as initial_padding. And it will offset the timestamps, but it rounds the timestamps to the timebase of the Matroska file (usually 1ms). [21:23:37 CEST] <mkver> So an opus block with timestamp 0 (before taking CodecDelay into account) and CodecDelay will leave the demuxer with a timestamp of -7ms. [21:24:58 CEST] <mkver> Possible solution: Use a finer timebase for a track with CodecDelay. [21:25:14 CEST] <mkver> But this has side-effects by claiming to be more precise than it is. [21:26:36 CEST] <Lynne> its better than having everything muxed be downgraded to 1/1000 timebase [21:26:56 CEST] <mkver> Think about it this way: You have an audio track with a default duration of 21 1/3ms (AAC) and an encoder delay of 21 1/3. [21:27:24 CEST] <mkver> The possible solution that I am currently talking about is for problem 3 (for the demuxer). [21:27:51 CEST] <mkver> Btw: Michael, did you receive my mail that I just sent? [21:28:04 CEST] <Lynne> though I did hear that matroska files with non-standard (!= 1/1000) timebases break a lot of demuxers [21:28:48 CEST] <mkver> These demuxers would then be broken, obviously. [21:29:08 CEST] <mkver> (Except if there are for WebM only, as WebM requires a 1ms timebase.) [21:29:25 CEST] <mjbshaw> mkver: I haven't received anything. [21:29:34 CEST] <mkver> I'll resend it. [21:33:42 CEST] <mjbshaw> For #3, the way I've handled it (outside of FFmpeg) is to claim all audio streams in MKV have a time_base of 1/sample_rate (and only non-audio streams use the container's 1/1000 (or whatever) timebase). [21:34:28 CEST] <mkver> Back to the demuxer problem: The actual timestamps are -21 1/3ms, 0ms, 21 1/3ms, 42 2/3ms, ..., but the timestamps of the blocks are 0, 21ms, 43ms,... (i.e. from these timestamps alone it appears as if the second packet had a longer duration than the first). [21:36:04 CEST] <mkver> If one now uses a finer timebase to export this stream (one fine enough to signal the CodecDelay) and simply offsets all timestamps by the CodecDelay, then the fact that some packets have a duration of 21ms and some of 22ms will remain. [21:37:18 CEST] <mkver> But with the 1ms timebase this could be put down to being a side-effect of the timebase (so it did not really signal that there were gaps). [21:38:15 CEST] <mkver> This changes when the demuxer exports this with a finer timebase. Now the track really looks as if it had some gaps and some parts where the audio from two packets should be played simultaneously. [21:39:06 CEST] <mkver> To solve this one would have to interpolate the timestamps (via their duration). [21:39:50 CEST] <mjbshaw> This example is audio, right? Are the packet times/durations not perfectly representable using a time base of 1/sample_rate? If not, wtf kind of audio codec is emitting fractional audio frames? [21:40:49 CEST] <mkver> It is an audio example (based upon AAC). [21:41:17 CEST] <mkver> Lots of audio packets duration can't be perfectly represented in Matroska. [21:41:50 CEST] <mkver> That's because most common sample rates have a 3 in their factorization. [21:42:21 CEST] <mkver> 1/sample rate is not a multiple of ns then and so is not perfectly representable in Matroska. [21:43:23 CEST] <mkver> And the number of samples in an audio packet doesn't have a three in its factorization, then the duration of said packet won't be perfectly representable either. [21:44:33 CEST] <mkver> This applies to most codecs: DTS (512 samples (10 2/3 ms)), AAC (1024 samples), certain modes of flac... [21:45:12 CEST] <mjbshaw> I need to look at matroskadec.c, but in my own demuxer+player (which handles WebM) I "lie" about the time base of streams contained in MKV/WebM. [21:45:23 CEST] <mjbshaw> Audio streams all get reported as having a time base of 1/sample_rate. [21:45:32 CEST] <mjbshaw> Video streams get a time base of whatever the container says. [21:45:49 CEST] <mjbshaw> Doing this in ffmpeg would fix the rounding issue in the demuxer. [21:45:50 CEST] <mkver> AC3 is fine though (at 48kHz): 1536 = 3 * 512 has a duration of 32ms. [21:46:19 CEST] <mkver> And how do you fix up the issue I talked about earlier? [21:46:46 CEST] <mjbshaw> Which one :) [21:47:36 CEST] <mkver> You have real timestamps of 0ms, 21 1/3ms, 42 2/3ms..., but the container only contains the timestamps of 0, 21ms, 43ms (timebase 1ms). [21:48:36 CEST] <mkver> If you now simply convert this to (say) 48kHz, then do you make it by multiplying 21*48 and 43*48 or do you actually interpolate the real timestamps? [21:49:40 CEST] <mkver> (I.e. do you take into account that 21ms and 43ms are not the real timestamps, but just the approximations in the 1ms timebase and fix them up to 21 1/3ms and 42 2/3ms before converting them to the 1/sample rate timebase?) [21:49:44 CEST] <nevcairiel> slightly jittery timestamps for audio is something everyone should be handling already anyway, its also not so bad since after decoding you can just make them sample accurate and just check it doesnt drift apart [21:50:12 CEST] <mjbshaw> The player ignores the PTS of audio packets except for when seeking. [21:50:41 CEST] <mkver> So it just plays them as it finds them and doesn't care. [21:50:47 CEST] <mjbshaw> As nevcairiel said, audio timestamps suck anyway and so the only way to really handle this in a player is to ignore the timestamps when playing contiguously. [21:51:25 CEST] <mjbshaw> So the first packet gets its timestamp from the container (lossily converted to a timebase of 1/sample_rate). [21:51:29 CEST] <nevcairiel> Thats what I do too. Primarily just keep a "counter" based on decoded samples and check that it doesn't drift apart from the timestamps, in which case something would be wrong [21:51:49 CEST] <mjbshaw> Subsequent packets get their timestamp by doing previous_packet_pts + previous_back_duration and ignoring the container's PTS. [21:52:20 CEST] <mjbshaw> where previous_back_duration is a sample-accurate duration of the packet. [21:53:19 CEST] <nevcairiel> for the record, while such logic is fine for a decoder or player to perform, a demuxer should just spit out the container timestamps, and let the other layers then ignore them (or use them :P) [21:55:00 CEST] <mkver> mjbshaw: I hope you are at least doing dome sanity checks and don't completely ignore container pts. [21:55:43 CEST] <mkver> nev, what do you think of the strategy I outlined at the end of this post: https://forum.doom9.org/showthread.php?p=1848928#post1848928 ? [21:56:42 CEST] <mjbshaw> mkver: Eh, there's only one of two options if the container PTS drifts horribly away from the sample-accurate timing based on actual contents. At that point the file is broken, and you can either continue playing it (what I do) or not (e.g., seek, warn the user, etc.). [21:57:26 CEST] <mjbshaw> Anyway, the advantage of reporting the audio stream's timestamps using a timebase of 1/sample_rate is that you can then accurately represent stuff like the codec delay. [21:57:33 CEST] <mkver> Ok, makes sense. [22:00:27 CEST] <nevcairiel> mkver: that sounds way too complicated just to avoid a tiny bit of timestamp jitter which is inherent to many container formats [22:01:29 CEST] <mkver> I somehow expected this from you. [22:02:15 CEST] <nevcairiel> its really nto a problem that needs solving :) [22:02:34 CEST] <nevcairiel> there is so many problems that do, rather invest time in those, personally [22:03:48 CEST] <mkver> Back to the rounding issues. Maybe we are thinking about this to complicated. Maybe we should simply use a different rounding method. One that does not round down -6.5ms and round up 13.5ms. [22:04:37 CEST] <mkver> If both are rounded the same, the 1ms gap is gone. [22:07:12 CEST] <mjbshaw> I'd be fine with that. Not quite as complete of a solution, but it's suuuper simple. [22:07:49 CEST] <mkver> Yeah, simplicity rules. [00:00:00 CEST] --- Fri May 31 2019

1 0

ffmpeg.log.20190530
by burek 31 May '19

31 May '19

[00:26:51 CEST] <bencc> when I generate animated gif from mp4 it looks very pixelated: [00:26:53 CEST] <bencc> ffmpeg -i test.mp4 -vf "crop=620:680:330:20" -q:v 1 test.gif [00:27:13 CEST] <bencc> isn't "-q:v 1" best quality? or maybe the problem is with colors and not quality? [00:27:38 CEST] <BtbN> A gif only has 256 colors [00:27:43 CEST] <BtbN> it's bound to look horrible [00:28:03 CEST] <kepstin> bencc: you should be using the palettegen/paletteuse filters, they provide more control over the colour reduction/dithering and should give better results [00:28:09 CEST] <BtbN> There is some 2pass palettegen magic that does the best it can, but it's still far from great [00:28:24 CEST] <kepstin> yeah, it's best to just not use gif [00:28:40 CEST] <BtbN> Luckily, gifs are pretty dead, since every browser can just play videos now [00:29:10 CEST] <kepstin> pretty much every online "gif" host actually serves up video files since they're smaller :) [00:29:17 CEST] <bencc> trying palettegen [00:29:28 CEST] <kepstin> (often converting uploaded gif to mp4 or webm) [00:32:10 CEST] <bencc> with palettegen/paletteuse the quality is great [00:32:45 CEST] <bencc> how can I crop and use paletteuse together? [00:32:51 CEST] <bencc> this gives me an error: [00:32:53 CEST] <bencc> ffmpeg -i test.mp4 -vf "crop=620:680:330:20" -i palette.png -filter_complex "[0:v][1:v] paletteuse" -q:v 1 test.gif [00:41:25 CEST] <kepstin> bencc: need to combine the two filter expressions into one. something like this would work: `-filter_complex "[0:v]crop=620:680:330:20[cropped]; [cropped][1:v]paletteuse" [00:46:19 CEST] <bencc> kepstin: works great. I'll read about [0:v] and [1:v]. thanks [09:44:19 CEST] <dongs> hmm so [09:44:48 CEST] <dongs> Video: HVC1 7680x4320 59.94fps [V: hevc main 10, yuv420p10le, 7680x4320 [default]] [09:44:54 CEST] <dongs> this actually plays OK at full speed on RTX2080 [09:45:06 CEST] <dongs> but goes at like 15fps on Quadro P2000 [09:46:03 CEST] <dongs> https://developer.nvidia.com/video-encode-decode-gpu-support-matrix the only difference between pascal and rtx is addition of 4:4:4 HEVC support [09:52:42 CEST] <dongs> Turings new NVDEC decoder has also been updated to support decoding of HEVC YUV444 10/12b HDR at 30 fps, H.264 8K, and VP9 10/12b HDR. [09:52:45 CEST] <dongs> i guess thats why [09:52:49 CEST] <dongs> ref: https://devblogs.nvidia.com/nvidia-turing-architecture-in-depth/ [09:52:59 CEST] <dongs> so pascal nvdec is only up to 4K [09:53:02 CEST] <dongs> cc: JEEB [10:36:09 CEST] <an3k> Weird, it says even Turing is limited to 4K 8-Bit https://developer.nvidia.com/nvidia-video-codec-sdk [10:36:45 CEST] <an3k> forget that, got a splitsecond confused with H.264 :) [10:41:07 CEST] <Dachande663> Hi, is this the correct channel to ask filter questions? [10:41:12 CEST] <durandal_1707> yes [10:41:22 CEST] <an3k> Maybe you have the issue because the P2000 is GTX1050/GTX1060 level (GP106) while the RTX2080 it Quadro 5000/4000 level (TU104) [10:43:27 CEST] <an3k> uh hi durandal_1707. Regarding that zscale threading. About what price we approx. talk about? And what if we want zscale to be real multi-threaded? :) [10:46:49 CEST] <furq> i assume frame threading in lavfi would cost a pretty penny [10:47:01 CEST] <dongs> an3k: right, but someone on GTX1070/80 also cannot decode anywhere realtime. [10:48:11 CEST] <dongs> ohh, i see 8k on the link [10:48:12 CEST] <dongs> neat [10:48:24 CEST] <an3k> Is there a sample somwhere I could test? [10:48:31 CEST] <dongs> my file? sec. [10:48:41 CEST] <dongs> https://drive.google.com/open?id=1IV6C4CpD4k7lIhO0-TxqNjVOuLXZrcqX [10:48:44 CEST] <dongs> its a bit big [10:49:09 CEST] <dongs> so Pascal NVDEC is 8192 x 8192** [10:49:16 CEST] <dongs> where ** = Max resolution support is limited to selected Pascal chips [10:49:42 CEST] <an3k> yeah, the lower tier chips can't do it [10:49:43 CEST] <Dachande663> Great. I'm trying to do something which sounds fairly simple in my head, but I've gotten lost trying to merge filter options etc as this is my first time using ffmpeg for anything complex. [10:49:43 CEST] <Dachande663> I have an image and an mp4. I want to stitch the image to the start of the video as a single frame (not 1 second, literally just one frame). The image is the same size as the video, but sometimes it's out by a fractional amount which is giving me SAR issues. Audio should be used from video, obviously skipping that first frame with silence. So far, I have something that stitches an image to the video. [10:49:43 CEST] <Dachande663> Issue a) I can't seem to get the image to appear for less than one second. [10:49:43 CEST] <Dachande663> Issue b) I can't get the aspect ratios to be matched (it's okay to resize image to match as they're very close). [10:49:43 CEST] <Dachande663> What I have so far: [10:49:44 CEST] <Dachande663> ffmpeg -loop 1 -t 0.1 -i "cover.jpg" -i "video.mp4" -f lavfi -t 1 -i anullsrc\=channel_layout\=stereo\:sample_rate\=44100 -filter_complex "[0:v] [2:a] [1:v] [1:a] concat=n=2:v=1:a=1 [v] [a]" -c:v libx264 -c:a aac -pix_fmt yuv420p -strict -2 -y -map "[v]" -map "[a]" output.mp4 [10:49:44 CEST] <Dachande663> What I'm trying (unsuccessfully) to merge: [10:49:44 CEST] <dongs> but no mention of which ones, i would have expected 1070/1080 class to work it. [10:49:45 CEST] <Dachande663> ffmpeg -i "video.mp4" -loop 1 -t 1 -i "cover.jpg" -f lavfi -t 1 -i anullsrc\=channel_layout\=stereo\:sample_rate\=44100 -filter_complex "[1:v]scale=1080x608:force_original_aspect_ratio=decrease,pad=1080:608:'(ow-iw)/2':'(oh-ih)/2'[i];[0:v][0:a][i][2:a] concat=n=2:v=1:a=1[v][a]" -c:v libx264 -c:a aac -pix_fmt yuv420p -map "[v]" -map "[a]" -y output.mp4 [10:49:45 CEST] <Dachande663> Any ideas? [10:49:56 CEST] <dongs> an3k: yeah but how is 1080/1080ti "low"? [10:50:00 CEST] <dongs> you mean like titan or someshit? [10:50:06 CEST] <dongs> or quadro P5k ttype stufF? [10:50:33 CEST] <an3k> I don't mean the 1080/1080ti is low [10:50:48 CEST] <dongs> well above sample plays at around 10-15fps on ti with 100% nvddec utilaizaiton [10:50:56 CEST] <dongs> 60fps on 2080 with 64% nvdec utikl [10:51:03 CEST] <an3k> Like I said, the P2000 is GTX1050/GTX1060 level (GP106 chip) while the RTX2080 it Quadro 5000/4000 level (TU104 chip) [10:51:14 CEST] <dongs> correct [10:51:44 CEST] <an3k> I'll test with 1080ti and 1050ti. I think my 1050ti will instantly die [10:53:03 CEST] <dongs> oh damn, P2000 really is only GP104. so its the "3gb" 1060 class [10:53:17 CEST] <dongs> and 6gb 1060 is prolly the GP106 [10:55:13 CEST] <an3k> P2000 is GP104 [10:55:26 CEST] <dongs> yes, right [10:55:29 CEST] <dongs> so thats really trash [10:55:44 CEST] <an3k> oh sorry. I'm wrong [10:55:44 CEST] <an3k> https://developer.nvidia.com/video-encode-decode-gpu-support-matrix [10:56:25 CEST] <dongs> there seems to be 2 variations of 1050/ti as well [10:56:36 CEST] <dongs> theres 106 and 104 listed for 1060 [10:56:44 CEST] <dongs> which i assume is the 3/6gb versions [10:57:00 CEST] <Dachande663> Anyone know how to set -t option to be less than one second? [10:57:17 CEST] <an3k> Ok, I can play the file fine on both 1080ti and 1050ti. I don't get 60fps but definitely much more than 24fps [10:57:29 CEST] <dongs> hmm [10:57:38 CEST] <an3k> Both cards got utilized to 100% [10:57:46 CEST] <dongs> ah, 100%. right. [10:57:48 CEST] <dongs> what OS? [10:57:54 CEST] <an3k> Win10 x64 [10:58:15 CEST] <dongs> and 1050ti is ~same? or worse [10:58:47 CEST] <an3k> slightly worse [10:59:43 CEST] <dongs> the video renderer says its outputting at 30fps but its definitely worse than that [10:59:46 CEST] <dongs> with lots of dropped frames [10:59:54 CEST] <dongs> visually it looks more liek 15-ish for me [11:04:48 CEST] <an3k> Before I tested with MPC-HC DXVA2 and 1080Ti went up to 100% Video Decode and playback had only a few drops. [11:05:17 CEST] <an3k> Now tested with ffplay with hevc_cuvid and boy the video is laggy as hell.GPU is at 30% ish [11:05:28 CEST] <dongs> yes, cuvid sucks at this [11:05:32 CEST] <dongs> i also tried same [11:05:41 CEST] <dongs> cuvid i was getting around uh... < 5fps [11:06:01 CEST] <dongs> i think cuvid is dependent on number of actual cuda cores for decode [11:09:36 CEST] <an3k> Meanwhile I don't think so anymore. nVIDIA is artificially limiting the cards capabilities. [11:10:06 CEST] <dongs> hehe, well they certainly are on quadro vs consumer [11:10:13 CEST] <dongs> like the 'number of nevnc sessions' [11:10:17 CEST] <dongs> that is definitely a driver limitation [11:10:26 CEST] <an3k> Just found yesterday an extremely tiny patch (it basically changes a byte) that removes the nvenc limit on non-Quadro cards. [11:10:33 CEST] <dongs> haha :) [11:15:44 CEST] <an3k> 35 fps on 1050Ti and 45 fps on 1080Ti both MPC-HC x64 DXVA2 [11:18:31 CEST] <an3k> I get 35 fps on 1050Ti and 50 fps on 1080Ti both MPC-HC x64 CUVID [11:20:26 CEST] <an3k> With CUVID the 1080Ti is utilized ~50% CUDA, 90% NVDEC, 20% 3D. With DXVA2 it's just 100% NVDEC [11:20:44 CEST] <dongs> hmm my cuvid setup is fucked then [11:20:53 CEST] <dongs> bceause it uses very little nvdec and just plays at garbage fps [11:23:20 CEST] <an3k> Hmm, maybe it's the RAM on the card. [11:24:08 CEST] <an3k> My 1050Ti (4GB) utilizes ~25% CUDA, 25% NVDEC and lags like hell but RAM is utilized 100% [11:26:46 CEST] <durandal_1707> i have patch for slice threaded zscale filter on ffmpeg-devel mailing list [11:46:22 CEST] <an3k> awesome, thank you very much! I'll test asap [12:01:04 CEST] <dongs> fwif, VLC 3.0.5 crashes almost instantly on that 8k video :p [12:01:13 CEST] <dongs> i downloaded .6 but didnt try [12:01:14 CEST] <dongs> so whatevr [12:01:30 CEST] <dongs> does vlc these days also use libavcodec for decoe? [12:01:34 CEST] <dongs> or they still rollin their own shit [12:12:43 CEST] <Dachande663> Any help? :( [12:13:17 CEST] <pink_mist> Dachande663: your question seems odd ... -t 0.1 should work just fine [12:13:35 CEST] <Dachande663> I tried that, but the frame still appears for 1 second [12:14:10 CEST] <pink_mist> it matters where in the commandline you place your -t [12:14:12 CEST] <Dachande663> (using VLC to step through slowly, unless there's a better way to confirm) [12:17:23 CEST] <Dachande663> the command is as per my message, do I need to move that argument? [12:28:41 CEST] <Dachande663> Okay, I've found a hacky way around by seeking to 0.95 in output to cut all but last frame. Just working on resizing the image now so it always matches the videos aspect ratio. Any idea how to merge "[0:v] [2:a] [1:v] [1:a] concat=n=2:v=1:a=1 [v] [a]" with "[1:v]scale=1080x608:force_original_aspect_ratio=decrease,pad=1080:608:'(ow-iw)/2':'(oh-ih)/2':setsar=1"? [12:34:01 CEST] <durandal_1707> Dachande663: where to put scale and others, before concat or after it? [12:34:14 CEST] <Dachande663> before [12:34:22 CEST] <Dachande663> I'm trying to scale the image so that it matches the video [12:34:39 CEST] <durandal_1707> Dachande663: you can use scale2ref [12:34:42 CEST] <durandal_1707> filter [12:35:35 CEST] <Dachande663> assume I'm an idiot who sees the filter syntax as voodoo, do I put that fitler after [1:v] ? [12:38:21 CEST] <durandal_1707> if you can not uderstand filter syntax after carefully reading and looking at documentation and still trying its way by monkeying around - get some mothly payware gui software instead [12:39:00 CEST] <durandal_1707> *monthly [12:42:48 CEST] <Dachande663> I spend most of my day in vcl and python, so I'm still learning the filter syntax. This job will run on a headless server so a GUI isn't an option. I won't rise to your bait, don't worry. [12:57:32 CEST] <durandal_1707> Dachande663: well, if you gonna rescale each input of concat filter that will make very long command [12:58:11 CEST] <Dachande663> I only need to resize the image to match the video. [12:58:19 CEST] <Dachande663> and that's assuming this is the problem: [12:58:35 CEST] <Dachande663> `Input link in1:v0 parameters (size 540x304, SAR 2204:2205) do not match the corresponding output link in0:v0 parameters (540x304, SAR 2567:2565)` [12:58:49 CEST] <Dachande663> it's the SAR which differs, even though the dimensions are the same? [12:58:58 CEST] <durandal_1707> yes [12:59:55 CEST] <Dachande663> would setsar work? [13:00:46 CEST] <durandal_1707> so basically use: [0:v]scale,setsar[a];[1:v]scale,setsar[b];[a][b][1:a]concat..... [13:01:55 CEST] <durandal_1707> or [2:a] ... depending what you really need [13:03:15 CEST] <Dachande663> amazing! that was the last bit I needed [13:03:32 CEST] <Dachande663> I have it working now based on that [13:03:37 CEST] <Dachande663> thank you for your help [15:14:29 CEST] <kingmoses> Hi. I am getting error -11 (Resource temporarily unavailable) when i do AvcodecReceiveFrame for mp4 file of h264 high. The h264 main are working just fine. What can i do? [15:17:21 CEST] <JEEB> kingmoses: are you jsing sw decoding and are you oushing enough packets into the decoder? [15:17:41 CEST] <JEEB> both frame threads and bframes require delay until the decoder can output frames [15:18:05 CEST] <kingmoses> A delay of how long? [15:19:20 CEST] <JEEB> depends, keep feeding and attempting to receive until you get a ftame out [15:20:17 CEST] <JEEB> both main and high profile stuff should not have any difference with it. just that high profile more likely also does bframes [15:20:43 CEST] <kingmoses> Okay. Let me check on it. [15:37:00 CEST] <kingmoses> JEEB: that has worked. Do you links where i can read about possible errors? It will help me determine whether i need to keep feeding the frames. [19:01:38 CEST] <mifritscher> moin [19:02:13 CEST] <mifritscher> is there a option to avformat_open_input() to let it ignore audio alltogether? [19:16:44 CEST] <mifritscher> ffmpeg has the option -an - it seems - what is the equivalent option for avformat_open_input? [20:28:49 CEST] <DHE> mifritscher: there is no specific option. examine the opened input and just ignore audio streams that you find [20:29:30 CEST] <mifritscher> ok, then the data from this stream of the e.g. network stream is simply discarded? [20:55:48 CEST] <kepstin> mifritscher: when you read from the avformat it'll return all packets received, you must explicitly discard packets for streams you are not interested in [20:59:18 CEST] <mifritscher> else I'll have a big memory leak I assume? [20:59:36 CEST] <kepstin> you'll have to unref the packets to avoid a memory leak, yes. [21:03:29 CEST] <mifritscher> ah, ok, this is done [21:03:51 CEST] <mifritscher> (I'm using libav not directly, but vja JavaCV) [21:08:19 CEST] <mifritscher> its of the structure [21:08:24 CEST] <mifritscher> while (true) { [21:08:24 CEST] <mifritscher> av_read_frame(oc,pkt); [21:08:24 CEST] <mifritscher> if (pkt.stream_index() == video_st.index()) { avcodec_decode_video2(video_c, picture, got_frame, pkt);) [21:08:24 CEST] <mifritscher> if (pkt.stream_index() == audio_st.index()) { avcodec_decode_audio4(audio_c, samples_frame, got_frame, pkt2);) <- I can simply remove this line and get no side effects? (*) [21:08:25 CEST] <mifritscher> av_packet_unref(pkt); [21:08:26 CEST] <mifritscher> } [21:08:52 CEST] <mifritscher> is (*) right? [21:09:56 CEST] <mifritscher> (I've omitted some details to get to the core ;) ) [21:12:46 CEST] <mifritscher> this would help me very much [21:20:41 CEST] <kepstin> mifritscher: seems correct. [21:20:51 CEST] <mifritscher> very good :-) [21:20:56 CEST] <mifritscher> thanks for your help! [21:28:35 CEST] <jeaye> I'm trying to encode an mp4 for viewing on mobile. Every single one of these works on Android (Pixel XL), but none of them do on iOS (tried with SE and X). Videos: http://73.223.67.2:3449/ [21:28:40 CEST] <jeaye> I've specifically followed the iOS-specific docs here: https://trac.ffmpeg.org/wiki/Encode/H.264 [21:28:50 CEST] <jeaye> What am I missing? [21:31:33 CEST] <jeaye> Info on my ffmpeg and the source file used: https://gist.github.com/jeaye/6da9255a4b5d3036f3ff9382c043bc05 [21:32:49 CEST] <kepstin> codecs etc. seem fine. did you use "-movflags faststart" when making the files? I'm not sure if ios requires that but it certainly wouldn't hurt. [21:34:20 CEST] <jeaye> Nope. The exact command used is included above each video. I can give it a shot. [21:36:14 CEST] <kepstin> I dunno what the exact issue you're having is, but here's a few more odd things: your webserver is using "video/mp4; charset=utf-8" as the mime type, that charset shouldn't be present [21:36:47 CEST] <kepstin> also most mobile browsers block autoplay. you might need to add controls to the tag so that they actually get a play button. [21:37:25 CEST] <jeaye> Ah, good point on the controls. [21:37:51 CEST] <kepstin> if you're seeing just the first frame displayed as a still image on ios, that's probably the issue. [21:40:51 CEST] <jeaye> Lots of good info. Thanks so much. Looking into it all now. [22:33:47 CEST] <jeaye> kepstin: Turns out they _all_ work on iOS. I had originally encoded the MP4 from a WebM file, which doesn't work on iOS, but then it didn't work either. That's what lead me to try all of these different profiles, but it turned out none of them did either. [22:35:02 CEST] <jeaye> After all of it, every single MP4 works fine on both the iOS devices. The issue was the original HTTP server and how it was serving them up. The one I showed you worked (which has charset for mp4, which is odd). The other one, which doesn't work, didn't have charset and also responded somewhat differently. [22:35:31 CEST] <jeaye> Anyway, turns out it has nothing to do with encoding or ffmpeg, but your tips were helpful. Thank you! [23:12:31 CEST] <an3k> Is there anything interesting? https://github.com/DolbyLaboratories/dolby-encoding-engine/tree/master/plug… They have x265 and ffmpeg stuff in there [23:39:47 CEST] <kepstin> an3k: nothing really that exciting, it's just an app that encodes/decodes videos and links to various open source libraries to do so. I don't see any ffmpeg/x265 code in there, just stuff that uses it, so I assume they use unmodified upstream versions. [23:41:12 CEST] <furq> anything that takes their attention away from pushing AC-4 is fine by me [23:41:41 CEST] <kepstin> they released that code under BSD license which is fine, but unless they're shipping a commercially licensed libx264 then their shipped binaries would be GPL v2, fwiw. [23:44:08 CEST] <kepstin> lol, their docs have dolby encoding engine users build the x265 plugin themselves, presumably to sidestep this issue. [23:45:19 CEST] <kepstin> https://developer.dolby.com/globalassets/professional/product-manuals/dolby… - "Note: Dolby Encoding Engine does not include an HEVC encoder but requires such an encoder to be installed" [23:45:52 CEST] <kepstin> I haven't checked, but as long as they're shipping a dynamically linked lgpl build of ffmpeg there shouldn't be any issues there. [00:00:00 CEST] --- Fri May 31 2019

1 0

ffmpeg-devel.log.20190529
by burek 30 May '19

30 May '19

[01:36:51 CEST] <cone-214> ffmpeg 03Andreas Rheinhardt 07master:cfe4389d4770: cbs_mpeg2: Correct and use enum values [01:36:51 CEST] <cone-214> ffmpeg 03Andreas Rheinhardt 07master:9c3f2a8894a6: cbs_mpeg2: Improve checks for invalid values [01:36:51 CEST] <cone-214> ffmpeg 03Andreas Rheinhardt 07master:de5880383967: cbs_mpeg2: Fix storage type for frame_centre_*_offset [01:36:51 CEST] <cone-214> ffmpeg 03Andreas Rheinhardt 07master:1759a9e5b52d: cbs_mpeg2: Correct error codes [01:36:51 CEST] <cone-214> ffmpeg 03James Almer 07master:d903c09d9a5c: avcodec/cbs_mpeg2: fix leak of extra_information_slice buffer in cbs_mpeg2_read_slice_header() [06:56:23 CEST] <mkver> @jkqxz: Would you mind using xuis as a name for a macro that is like xui, but takes a string argument and does not stringify its argument? [06:56:33 CEST] <mkver> xui would of course expand to xuis. [06:58:12 CEST] <mkver> The 's' is unfortunately already in use for subscripts, but given that xui already contains the possibility of subscripts, no need for a macro that is like xui but takes subscripts will every arise. [10:31:06 CEST] <durandal_1707> can one resize dvdsub subtitles? [10:32:17 CEST] <JEEB> theoretically yes. I've even seen people do HD DVD subtitle streams [10:32:26 CEST] <JEEB> (which I'm not really sure why they'd do it) [10:32:33 CEST] <TheAMM> I've seen 1080p vobsubs, ye [10:32:51 CEST] <JEEB> since the source is usually BD subs anyways [10:33:28 CEST] <durandal_1707> so what they use? [11:01:58 CEST] <cone-835> ffmpeg 03Paul B Mahol 07master:02333fe394f0: avformat/gif: abort early if nothing was written yet [13:35:00 CEST] <vel0city> several decoders (and probably encoders) have "type" or "mode" vars [13:35:28 CEST] <vel0city> but why are their values #defines instead of enums? [13:35:53 CEST] <vel0city> an example would be libavcodec/sunrast.h [13:36:51 CEST] <durandal_1707> using enum instead of few defines seems overkill [13:37:21 CEST] <vel0city> I fail to see the benefit of defines [13:37:30 CEST] <vel0city> if anything they are slower to write [13:37:53 CEST] <vel0city> anyway, I wanted to do something similar for TIFF and my first thought was of course enums but now I'm not so sure [13:38:05 CEST] <durandal_1707> for what? [13:38:23 CEST] <vel0city> TIFF, DNG, CinemaDNG [13:38:23 CEST] <durandal_1707> dont use enums for single items [13:38:59 CEST] <vel0city> single items? [13:39:11 CEST] <durandal_1707> enum with only one entry [13:39:13 CEST] <vel0city> I want to detect CinemaDNG to handle the case we talked about [13:39:26 CEST] <vel0city> there will be 3 enum entries, the ones I listed [13:39:56 CEST] <durandal_1707> then use enum, i think nobody will insist to use define [13:40:03 CEST] <vel0city> cool [14:23:45 CEST] <ePirat> wbs, should I do something for http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/244469.html ? [14:39:05 CEST] <wbs> ePirat: maybe ping it? as the build fails with versions of xcode that have this warning if targeting an older version, it'd be good to have that fixed as well, but I guess that's an almost separate issue [14:39:49 CEST] <ePirat> in what case does the build fail? [14:40:17 CEST] <wbs> if you build with -mmacosx-version-min=10.11 [14:41:09 CEST] <wbs> because it requires more metadata indicating "I've checked for this function now, so it's ok to use it [14:41:44 CEST] <wbs> or I just mistested it without your patch when I looked at it [19:39:29 CEST] <mkver> Could please someone explain to me the difference between AV_HAVE_BIGENDIAN and HAVE_BIGENDIAN? [19:39:51 CEST] <mkver> Is it because of mixed endian processors? [19:40:49 CEST] <nevcairiel> one is from config.h, not exported, one from avconfig.h, exported? [19:43:45 CEST] <mkver> So there are no systems for which these two macros differ? [19:45:23 CEST] <nevcairiel> should not [19:45:50 CEST] <mkver> Good. [20:18:51 CEST] <jdarnley> I'd be surprised if ffmpeg supported such a system. [20:19:40 CEST] <jdarnley> after all several things are required [20:19:55 CEST] <jdarnley> sizeof int and twos complement being two [00:00:00 CEST] --- Thu May 30 2019

1 0

ffmpeg.log.20190529
by burek 30 May '19

30 May '19

[00:06:52 CEST] <bencc> TheAMM: this is just crop [00:06:58 CEST] <bencc> can I remove background? [00:07:04 CEST] <bencc> not sure what you mean by rips [00:08:21 CEST] <TheAMM> Hm, your description sounded like you had one of those videos where they add a border and place the actual video inside it to avoid copyright detection, downloaded from youtube [00:09:42 CEST] <bencc> I'm not violating anything [00:10:09 CEST] <TheAMM> If the background is a static color, https://ffmpeg.org/ffmpeg-filters.html#chromakey [00:11:33 CEST] <TheAMM> Otherwise your best bet is to take the first frame (or one you've edited yourself from the frames to have only the background), compare it to all the others and generate a mask from that [00:13:01 CEST] <bencc> I think I need to remove only 4 colors [00:13:22 CEST] <bencc> it's animated gif over a website screenshot [00:13:39 CEST] <bencc> but using chromakey will probably remove also part of the cartoon [00:13:53 CEST] <bencc> how can I tell which color to use with the chromakey filter? [00:14:17 CEST] <BtbN> That most definitely will also damage the actual video [00:14:28 CEST] <BtbN> There is no trivial way to remove a background picture [00:14:37 CEST] <bencc> ok [00:14:48 CEST] <bencc> I'll ask the animator to give me a better video [00:15:01 CEST] <bencc> he placed the cartoon over a background to make it look real [00:15:14 CEST] <bencc> but I need it without the background and thought there is a way to do it [00:16:11 CEST] <Bruc3Wayn3> easiest way is for him to give it to you [00:16:28 CEST] <bencc> sure. thanks [00:16:53 CEST] <bencc> I want to try the chromakey anyway [00:16:58 CEST] <bencc> how to detect the color? [00:17:05 CEST] <bencc> take a screenshot of the video and use gimp? [00:17:11 CEST] <BtbN> Pretty much, yes [00:17:25 CEST] <BtbN> keep in mind it operates on YUV, not RGB [00:19:04 CEST] <bencc> ok [00:43:31 CEST] <Montana> ffmpeg is very stable but ffmpeg on OBS-studio is very unstable. why is that? [00:45:09 CEST] <BtbN> "On OBS-Studio"? [00:46:54 CEST] <Montana> btbn yup, popular program that uses ffmpeg [00:47:20 CEST] <BtbN> I know what it is, I just don't understand that statement. [00:47:42 CEST] <Montana> ffmpeg is very stable but ffmpeg that is used in OBS-studio is very unstable. why is that? [00:48:16 CEST] <Montana> is that better? [00:48:30 CEST] <BtbN> So, what doesn't work? [00:48:46 CEST] <Montana> audio only recording [00:48:55 CEST] <Montana> using vp9 codec doesn't work [00:49:20 CEST] <BtbN> What container? [00:49:25 CEST] <Montana> webm [00:49:31 CEST] <Montana> mkv [00:49:34 CEST] <Montana> tried both [00:49:49 CEST] <BtbN> well, those are effectively the same, and not what's stopping it [00:49:50 CEST] <Montana> btbn do you use obs-studio? [00:50:02 CEST] <BtbN> I'd guess their ffmpeg libs are just built without a vp9 encoder? [00:50:05 CEST] <Montana> btbn it crashes using vp9 [00:50:26 CEST] <Montana> no it has vp9 encoder lib [00:50:48 CEST] <Montana> because it creates vp9 files but crashes [00:52:27 CEST] <BtbN> You should report that to them, not ffmpeg [00:53:08 CEST] <BtbN> There is no ffmpeg command line, it's a 3rd party program usinb lavc [00:53:43 CEST] <BtbN> Probably API-Misuse on their end or something [00:53:55 CEST] <another> i aassumed there would be some setting for an ffmpeg cmdline [00:54:15 CEST] <Montana> okay let me check the command line that it excutes [00:54:18 CEST] <BtbN> It does not invoke a cli tool, that would be horribly inefficient [00:54:39 CEST] Action: another *shrugs* [00:54:41 CEST] <Montana> btbn it doesn't? i don't see why that would be inefficient [00:54:56 CEST] <BtbN> How would it gets the raw frames into it? [00:55:08 CEST] <BtbN> It just uses the API, like it should. But apparently incorrectly. [00:55:26 CEST] <Montana> btbn you seem to be expert in OBS [00:55:37 CEST] <BtbN> This has nothing to do with a specific program [00:56:52 CEST] <BtbN> Open a bug with them, give them a crashlog. It's most definitely not an ffmpeg issue [00:57:26 CEST] <Montana> exactly ffmpeg build from ffmpeg site is super stable [00:57:28 CEST] <Montana> it never crashes [00:57:35 CEST] <BtbN> ... [00:58:09 CEST] <BtbN> First, there are no ffmpeg builds on the ffmpeg site. Second, OBS is using the API, not the cli tools. [00:58:32 CEST] <Trel> Not sure if I should be asking this here or in -devel, but I'm trying to compile ffmpeg, and I have a library in a non-standard location. I'm not sure how to get it to find it for compiling, as well as work in the resulting binary, which shows it as not-found when I do use ldd. [00:58:57 CEST] <BtbN> Trel, make sure pkg-config finds it, then configure will most likely find it. [00:59:57 CEST] <Trel> I was able to get configure to find it, and it compiles, but it's the binary that seems to not work as it claims its missing. [01:00:55 CEST] <Trel> I used --extra-cflags and --extra-ldflags on configure to that effect [01:01:17 CEST] <SixEcho> is there a way to represent "ffmpeg -f concat -safe 0 -i concat.txt" as a complex filter? first attempt using the complex filter am getting 30fps vs 1600+ [01:01:18 CEST] <tdr> Trel, on linux? [01:01:23 CEST] <Trel> Yes [01:01:39 CEST] <BtbN> SixEcho, there is a concat filter, but it works at a very different level [01:01:49 CEST] <BtbN> And forces a reencode [01:02:04 CEST] <tdr> Trel, add the path to your /etc/ld.so.conf or a file inside of /etc/ld.so.conf.d then run ldconfig [01:02:21 CEST] <Trel> tdr: need to do this as non-root only [01:02:40 CEST] <tdr> then play with your shell environment library paths [01:02:42 CEST] <Trel> That's where 99% of my headaches with this stem from [01:03:07 CEST] <tdr> i think the headaches are form odd locations for things ;) [01:03:24 CEST] <inna> hey [01:03:40 CEST] <BtbN> You can also do -Wl,-rpath,\$ORIGIN during linking and then just put the library next to the binary [01:03:49 CEST] <inna> should i expect issues having my whole source and bin directory ntfs compressed? [01:04:25 CEST] <tdr> BtbN, that's a workaround though. better to fix the environment or make the library global. [01:04:47 CEST] <BtbN> Can't really make a library global if you're not root. And generally not a good idea to do that for custom build stuff as well [01:05:11 CEST] <tdr> thats the purpose of /usr/local tho .. its commonly done [01:05:19 CEST] <BtbN> And it commonly makes a mess [01:05:22 CEST] <tdr> "global" but local to the system [01:05:36 CEST] <tdr> not if the lib doesn't over-lap one already provided by something else [01:06:03 CEST] <BtbN> Until it at some point in the future does, and headers/libs get mixed, and you end up with weird crashes [01:06:26 CEST] <BtbN> Everything outside your homedir is better done by a package manager [01:06:48 CEST] <tdr> /usr/local is mostly never touched by a package manager [01:06:59 CEST] <BtbN> So? [01:07:06 CEST] <BtbN> It can just stay empty [01:07:52 CEST] <tdr> keeping it in $HOME and trying to share it can be awkward tho too [01:08:02 CEST] <Montana> btbn does your obs crash too when you use vp9 ? [01:08:05 CEST] <BtbN> Yes [01:08:15 CEST] <Montana> btbn is that Yes to me? [01:08:16 CEST] <BtbN> But the file it recorded works fine at least [01:08:27 CEST] <BtbN> It only crashes on stop [01:08:34 CEST] <Montana> btbn yes same here [01:08:50 CEST] <BtbN> It's most likely misusing the API, like I said. File a bug with them. [01:09:11 CEST] <BtbN> Looking at the backtrace, it looks like it kept feeding frames to the encoder after it closed it. [01:09:26 CEST] <Montana> btbn thanks for testing that [01:11:09 CEST] <Montana> btbn also try audio-only recording [01:11:41 CEST] <BtbN> I'm going to bed now, so not before tomorrow. [01:25:49 CEST] <Trel> tdr: that's what I said, I think I need to set some of this with the LDFLAGS envar, I'm trying that currently. I'm fairly certain rpath is the one I need to get set correctly. [01:26:40 CEST] <Trel> BtbN: I'm doing something similar, I set rpath with the LDFLAGS envar, but I set it to where I know the .so file it can't find should be, I'd like to avoid having the binaries and libraries mixing [01:31:30 CEST] <Trel> BtbN and tdr: setting LDFLAGS='-Wl,-rpath,/nonstandard/path/to/libs' ./configure <the rest>, did the trick [01:31:41 CEST] <Trel> Thanks for the assist [02:02:33 CEST] <Montana> does ffmpeg allow pausing while encoding? [02:04:14 CEST] <DHE> you can always SIGSTOP it or whatever. I'll assume it's not realtime work involved... [02:08:32 CEST] <Montana> is SIGSTOP stopping or pausing? [02:14:12 CEST] <c_14> SIGSTOP pauses, SIGCONT resumes [02:37:58 CEST] <causa-sui> I have been using ffmpeg to make short clips out of larger video files. With one, I want to make an "eternal loop" i.e. play the clip, then seamlessly play the clip in reverse back to the beginning. Would anyone be kind enough to help me figure out how? [03:13:58 CEST] <DHE> causa-sui: reverse is tricky. you'll probably want to turn the movie into individual frames (png, jpegs, whatever), reverse the filenames, and then re-encode a backwards video movie from that [03:14:12 CEST] <DHE> (or something to that effect) [03:36:22 CEST] <Atlenohen> kepstin: So I'd just need an utility which can output all the pkt_duration_time values from all frames, ... yeah something I wanted to type yesterday but fallen asleep [03:37:02 CEST] <Atlenohen> So yeah people, good evening, how would I possibly output just those values from FFPROBE, some kind of grepping in linux ? [03:37:27 CEST] <Atlenohen> I have MSYS2 maybe I could try that, and remove all the other putput ffprobe deoes when showing frames [03:55:57 CEST] <furq> Atlenohen: -show_entries frame=pkt_duration_time [04:00:29 CEST] <xochilpili> hello everyone [04:02:35 CEST] <xochilpili> im working in a personal project for iptv, now, i have found several information about hls, hsv. Then, i found several servers with live streaming using m3u8 file, now, how can i determine the name of the channel using ffmpeg or ffprobe or i just cant? [04:03:34 CEST] <xochilpili> if i cant using ffmpeg or ffprobe, then how can i determine the channel name ? [04:12:52 CEST] <DHE> ffprobe will show it if available, usually labeled "Service name" or such [04:19:48 CEST] <friendofafriend> After a few days of watching an MPEG-TS outputted from ffmpeg, the lag adds up to a few minutes. I can restart the viewer and it goes away. Is there some way to mitigate that? [11:36:24 CEST] <Pihamies> i got an ERROR: libx264 not found when trying to compile ffmpeg? [11:37:22 CEST] <Pihamies> i installed x264 with git clone https://code.videolan.org/videolan/x264.git;make;make install but still the same error [11:37:50 CEST] <BtbN> Use your distributions packages instead [11:38:37 CEST] <Pihamies> i did [11:38:51 CEST] <BtbN> You just described how you didn't. [11:38:55 CEST] <Pihamies> slackware's slackbuilds [11:39:05 CEST] <Pihamies> it compiles [11:39:37 CEST] <BtbN> If you do that manually, it still won't be in the proper paths, and not tracked by the package manager. [11:39:40 CEST] <Pihamies> slackbuild script uses ff 4.1.3 version [11:39:52 CEST] <BtbN> Make sure you also have the -dev package installed. [11:40:42 CEST] <Pihamies> where should i install x264, it now is in /usr/local/bin [11:41:34 CEST] <BtbN> You should use your distributions package for it, which will properly install it. [11:41:45 CEST] <Pihamies> where do i get the -dev package? [11:42:08 CEST] <BtbN> I have no idea about Slackware, but you get it from your distribution. [11:42:21 CEST] <Pihamies> i alrady have ffmpeg 4.1.3 installed, i was just trying to add x264 into it [11:42:33 CEST] <BtbN> That's not how that works [11:42:52 CEST] <Pihamies> it does with slackbuilds [11:42:55 CEST] <BtbN> ffmpeg needs to be compiled with support for libx264 [11:43:00 CEST] <BtbN> you can't add it in after the fact [11:43:10 CEST] <Pihamies> there is a conf option for x264 [11:43:20 CEST] <BtbN> Yes, at compile time [11:43:21 CEST] <Pihamies> it compiles it again [11:43:34 CEST] <Pihamies> then i upgrade the package [11:43:42 CEST] <BtbN> So Slackware has a Gentoo-Like build system package manager? But does not pull in dependencies on its own? [11:43:54 CEST] <Pihamies> right [11:44:25 CEST] <Pihamies> https://slackbuilds.org/repository/14.2/multimedia/ffmpeg4/ [11:45:03 CEST] <BtbN> That sounds horribly broken [11:45:54 CEST] <Pihamies> well it build 4.1.3 perfectly [11:46:09 CEST] <BtbN> With support for no external libraries, yes. [11:46:33 CEST] <BtbN> You can switch them on with env vars acording to that page, but it does not automatically pull in dependencies it seems, which is 100% broken imo [11:47:09 CEST] <BtbN> Only thing it actually seems to depend on is libass [11:47:31 CEST] <Pihamies> i set lib3blame in config and it built that just fine, only not x264 [11:47:50 CEST] <Pihamies> that's external lib too? [11:48:10 CEST] <BtbN> Of course it is [11:48:25 CEST] <Pihamies> i suspect it just doesn't find where the x264 is? [11:48:36 CEST] <BtbN> It should find its own dependency [11:48:46 CEST] <Pihamies> should i install x264 inti /usr? [11:48:48 CEST] <BtbN> You should complain to the Distribution [11:49:03 CEST] <BtbN> And you should install the libx264 system package, don't install stuff manually [11:49:20 CEST] <Pihamies> there wasnt' it [11:49:36 CEST] <Pihamies> so i had to use git [11:49:51 CEST] <BtbN> There is a x264 package if I go one patch up from that ffmpeg link... [11:49:54 CEST] <BtbN> *path [11:51:02 CEST] <Pihamies> right, good find [11:51:15 CEST] <Pihamies> how do i uninstall git x264? [11:51:39 CEST] <Pihamies> i havent used git much [11:51:58 CEST] <BtbN> try make uninstall. If it doesn't have that target, manually find all files it installed into the system and remove them [11:52:25 CEST] <Pihamies> yeah, i did, it removed it [11:52:34 CEST] <Pihamies> lemme install sb x264 [11:53:15 CEST] <BtbN> But what the hell is wrong with slackwares packages and dependencies? That seems horribly broken [11:54:17 CEST] <Pihamies> it doesn't do dependencies [11:54:38 CEST] <Pihamies> u have to install all one by one [11:54:51 CEST] <BtbN> That's horrible. [11:55:19 CEST] <Pihamies> yes, but luckily there ain't too many programs that have many [11:55:44 CEST] <BtbN> If I think about desktop envs and the like, that easily is a dependency tree with 100+ packages [11:55:48 CEST] <Pihamies> videolan has lots, that's why i rather use mplayer [11:56:04 CEST] <BtbN> mplayer and vlc both depend on ffmpeg, which depends on all the stuff [11:56:29 CEST] <BtbN> Also, mplayer is pretty dead, use mpv. [11:57:25 CEST] <Pihamies> not ffmpeg as u see in sb page there are no requirements other than libass [11:57:42 CEST] <Pihamies> i'm used to mplayer [11:58:03 CEST] <Pihamies> it doesn't do .vtt i just noticed few days ago [11:58:11 CEST] <BtbN> mpv is a maintained mplayer fork... [11:58:29 CEST] <Pihamies> ic, i give it a try [11:59:43 CEST] <Pihamies> looks like ffmpeg is now compiling with correct x264 ;) [12:01:00 CEST] <Pihamies> hmm i did seacrh first x264 from sb but i searched libx264 which it doesn't find [12:02:22 CEST] <Pihamies> btw, do u know what are good option to convert dvd into videofile with ffmpeg, thats why i'm installing x264 for [12:03:48 CEST] <BtbN> There's probably a wiki page about that somewhere on trac [12:04:13 CEST] <BtbN> DVDs are a mess though [12:06:07 CEST] <Pihamies> yes, i'm trying to convert it as good quality as possible [12:06:44 CEST] <Pihamies> just ffmpeg -i input.vob out.mp4 compresses it [12:07:14 CEST] <Pihamies> i tried .ts format too, but not much better [12:07:31 CEST] <Pihamies> which format does not compress or change quality? [12:09:03 CEST] <furq> use -c copy [12:09:19 CEST] <furq> also if you want to remux a set of vobs then use something like tccat from transcode [12:10:55 CEST] <Pihamies> i grabbed the .vobs with cat *.VOB into input.vob [12:11:35 CEST] <Pihamies> well it compiled and installed ffmpeg 4.1.3, how do i check it now has libx264 support? [12:12:24 CEST] <Pihamies> so is it ffmpeg -i input.vob -c copy out.mp4? [12:13:21 CEST] <Pihamies> got it, it's there [12:13:33 CEST] <furq> 11:10:55 ( Pihamies) i grabbed the .vobs with cat *.VOB into input.vob [12:13:43 CEST] <furq> this is the bit that you should ideally use a proper demuxer for [12:13:53 CEST] <furq> but if you're happy that input.vob actually contains exactly what you want then no need [12:14:51 CEST] <Pihamies> yes, it has whole video, but the output.mp4 is not good quality [12:15:42 CEST] <Pihamies> okay that -c copy did the trick ;) [12:15:54 CEST] <Pihamies> identical copy [12:16:44 CEST] <Pihamies> hmm, i guess i don't need that x264 into this after all ;) [12:17:05 CEST] <furq> not for just remuxing [12:17:39 CEST] <Pihamies> one guide on net mentioned it, i wish i knew this -c copy before ;) [12:24:06 CEST] <Atlenohen> I'm reading now that the FPS and Timecodes aren't exactly dependent on each other, interesting [12:25:05 CEST] <Atlenohen> But what if the FPS changes in the middle of a video, would that be achieved by just timings and still be as a CFR video or would it make it a VFR ? [12:25:40 CEST] <Atlenohen> Well, technically it not be CFR, ... technically matters tho. [12:25:50 CEST] <furq> well the framerate would be variable [12:26:42 CEST] <Atlenohen> Oh sorry, I wanted to say, that the constant FPS changes, let's say from 30 to 60 [12:26:47 CEST] <furq> yeah i get that [12:27:01 CEST] <BtbN> If that happens in the middle of a stream, it's clearly not CFR [12:27:16 CEST] <Atlenohen> It wouldn't make a difference right, yeah, just double checking. [12:27:32 CEST] <furq> the definition is helpfully encapsulated in the name [12:38:19 CEST] <Pihamies> this mpv is indeed better than mplayer, thanks BtbN [12:39:04 CEST] <TheAMM> Who'd've'thunk'd'it! [12:48:54 CEST] <an3k> Hello. I tried to solve it by myself but after hours of googling, thinking and trying I can't find a solution. I want to split this command into multiple ones because the filters are horribly slow. ffmpeg.exe -hide_banner -y -c:v hevc_cuvid -i "D:\Encode\input.mkv" -vf zscale=t=linear:npl=100,format=gbrpf32le,zscale=p=bt709,tonemap=tonemap=hable:desat=0,zscale=t=bt709:m=bt709:r=tv,format=yuv4 [12:48:54 CEST] <an3k> 20p,scale=1920:1080,crop=1920:1080:140:140 -c:v libx264 -profile:v high -level:v 4.1 -crf:v 22 -tune:v film -preset:v veryslow output.264 [12:51:22 CEST] <furq> i'm not sure i understand the question [12:52:16 CEST] <an3k> That command encodes with 2 fps on a 12-core 2.8 GHz Xeon; only one core is utilized. I read that the filter(s) are single-threaded. Since it's ffmpeg I assume I can use a single filter per ffmpeg process and pipe to another ffmpeg process so I get "multi-threading"? [12:52:45 CEST] <furq> you could but you'd still be bottlenecked by the slowest filter [12:53:25 CEST] <pink_mist> furq: sure, but the slowest filter would get a full core just for itself, rather than having to share it with all the other filters too [12:53:44 CEST] <furq> that still seems like it would give a worse speedup than just splitting the file into 12 and encoding them separately [12:53:52 CEST] <furq> and would also be more complicated [12:53:56 CEST] <an3k> I tried but I always get an error. I tried it with -f rawvideo, -f hevc and so on but nothing works [12:54:26 CEST] <TheAMM> Not literally split the source file [12:54:32 CEST] <an3k> Well, If I use AviSynth with the same filters and open that with ffmpeg and pipe the yuv240 output to x264 I encode with more than 30 fps [12:54:33 CEST] <TheAMM> But seek and read only a part of it [12:54:51 CEST] <an3k> Don't tell me AviSynth is more advanced than ffmpeg :) [12:55:06 CEST] <furq> i'm not really sure which of those filters is slow [12:55:49 CEST] <furq> why not just use avisynth though [12:56:40 CEST] <an3k> The plugins are Windows only :( [12:56:53 CEST] <furq> vapoursynth? [12:57:07 CEST] <furq> if you're using regular non-MT avs then i assume the reason is that one of those filters is badly optimised in ffmpeg [12:57:16 CEST] <furq> or badly optimised for the particular code path you're hitting, at least [12:57:50 CEST] <furq> i assume it's tonemap [12:58:49 CEST] <furq> vapoursynth has tonemapping stuff so it might be worth trying that out first [12:59:03 CEST] <an3k> I just tried with only -vf zscale=t=linear:npl=100,scale=1920:1080,crop=1920:1080:140:140 and that 8 fps (only one core utilized) [12:59:10 CEST] <furq> also obviously make sure your ffmpeg is up to date [12:59:42 CEST] <furq> you know zscale does scaling, right [12:59:58 CEST] <furq> and you should probably do that before running expensive filters [13:00:32 CEST] <an3k> in this case zscale does nothing but HDR -> SDR tonemapping [13:01:06 CEST] <furq> yeah i'm saying you should use it for scaling as well [13:01:39 CEST] <furq> going zscale,zscale,zscale,scale is a weird thing to do [13:01:57 CEST] <an3k> oh, right. I haven't fixed the actual resolution scaling filter yet, just added a simple one so x264 accepts it [13:02:13 CEST] <furq> how big is the source [13:02:19 CEST] <durandal_1707> easy - split input with segment muxer - filter and encode each component in paraller - WIN WIN! [13:02:45 CEST] <an3k> 51 GB [13:02:48 CEST] <furq> i meant resolution [13:02:50 CEST] <furq> i assume it's 4k [13:02:53 CEST] <an3k> 2160p [13:03:05 CEST] <furq> if it's 4k then scaling to 1080p before running anything else will make it about 4x quicker [13:03:15 CEST] <furq> you might get some minor quality loss obviously [13:05:14 CEST] <an3k> 6 fps now [13:05:35 CEST] <durandal_1707> tonemap got slice threading recently [13:05:51 CEST] <furq> do you need zscale,format,zscale [13:05:56 CEST] <furq> seems like you could merge those two zscales together [13:06:16 CEST] <an3k> Yes, otherwise tonemapping doesn't work [13:06:36 CEST] <furq> that's weird but i've never used tonemap so i'll assume it's true [13:07:04 CEST] <an3k> https://forum.doom9.org/showthread.php?p=1827930#post1827930 [13:07:13 CEST] <an3k> That one explains each filter [13:07:26 CEST] <durandal_1707> zscale=t=linear:npl=100:p=bt709,format=gbrpf32le,tonemap=tonemap=hable:desat=0,zscale=t=bt709:m=bt709:r=tv,format=yuv4 ? [13:08:33 CEST] <an3k> Then color information will be cut off. gbrpf32le has to come before bt709 [13:09:21 CEST] <an3k> If I could split the command and pipe ffmpeg into ffmpeg I could live with that. How should I do that? [13:09:57 CEST] <furq> it'd be a lot easier and probably faster to just split the input [13:10:09 CEST] <durandal_1707> see segment muxer and concat demuxer documentation [13:10:40 CEST] <furq> also yeah make sure your ffmpeg is up to date [13:11:18 CEST] <durandal_1707> nobody wants to pay me to improve zscale scalability so its soo slow [13:11:26 CEST] <furq> i guess you want git head because tonemap isn't threaded in 4.1.3 [13:11:27 CEST] <an3k> If I use ffmpeg.exe -hide_banner -c:v hevc_cuvid -i "D:\Encode\input.mkv" -vf zscale=w=1920:h=1080:t=linear:npl=100 -f rawvideo - | ffmpeg.exe -hide_banner -y -i - -vf format=gbrpf32le,zscale=p=bt709,tonemap=tonemap=hable:desat=0,zscale=t=bt709:m=bt709:r=tv,format=yuv420p -c:v libx264 -profile:v high -level:v 4.1 -crf:v 22 -tune:v film -preset:v veryslow output.264 or other formats like hevc, [13:11:27 CEST] <an3k> etc. I constantly get errors [13:11:51 CEST] <furq> you can't just pipe rawvideo like that [13:11:57 CEST] <furq> rawvideo doesn't have any headers indicating dimensions, pixel format etc [13:12:23 CEST] <furq> so you either need to specify those on the right hand side of the pipe, or do -f nut -c:v rawvideo on the left hand side [13:12:29 CEST] <furq> (do the second one) [13:12:32 CEST] <an3k> so put it in eg. mpegts before piping? [13:12:43 CEST] <an3k> oh [13:13:23 CEST] <furq> also you probably want to set a scaler for zscale [13:13:26 CEST] <furq> it defaults to bilinear iirc [13:13:34 CEST] <furq> probably :f=lanczos [13:14:36 CEST] <an3k> Now I get "Impossible to convert between the formats supported by the filter 'graph 0 input from stream 0:0' and the filter 'auto_scaler_0'" [13:15:38 CEST] <furq> remember when i said it'd be simpler to just split the input [13:15:42 CEST] <furq> well this isn't what i meant but i'll take it [13:16:38 CEST] <furq> i guess you need to move format=gbrpf32le into the first command [13:16:45 CEST] <an3k> Yeah but splitting the files isn't going to work. Encoding has to be done "on the fly" [13:16:50 CEST] <furq> oh [13:17:34 CEST] <an3k> code 3074: invalid colorspace definition \ Error while filtering: Generic error in an external library \ Failed to inject frame into filter network: Generic error in an external library [13:18:15 CEST] <furq> hell yeah incomprehensible zscale errors [13:18:42 CEST] <furq> going to take a wild stab in the dark and guess you need to move zscale=p=bt709 into the first command as well [13:18:43 CEST] <an3k> "format=gbrpf32le to turn it all into floating-point RGB" [13:19:19 CEST] <durandal_1707> zscale can use slice threading, i once again kindly ask for sponsorship [13:19:22 CEST] <furq> the important thing to remember about zscale errors is that at they're not segfaults [13:19:26 CEST] <furq> at least [13:20:08 CEST] <an3k> ok, put the 2nd zscale into the first part. Now I get "Impossible to convert between the formats supported by the filter 'graph 0 input from stream 0:0' and the filter 'auto_scaler_0' \ Error reinitializing filters! \ Failed to inject frame into filter network: Function not implemented" [13:20:47 CEST] <an3k> @durandal_1707 That is going to be expensive, isn [13:20:51 CEST] <an3k> 't it? :) [13:21:41 CEST] <furq> an3k: what ffmpeg version is this [13:22:12 CEST] <an3k> ffmpeg version 4.1 Copyright (c) 2000-2018 the FFmpeg developers [13:22:42 CEST] <furq> 12:05:35 (@durandal_1707) tonemap got slice threading recently [13:22:54 CEST] <furq> you should probably try git head and see if this helps you out [13:23:03 CEST] <furq> the latest git version on zeranoe has it [13:24:21 CEST] <furq> there are also community static builds of git head for linux if this needs to be portable [13:24:47 CEST] <furq> portable without having to build it yourself, i should say [13:25:45 CEST] <an3k> Just tried it with "ffmpeg version N-93944-gd903c09d9a Copyright (c) 2000-2019 the FFmpeg developers" [13:26:25 CEST] <an3k> same error [13:26:31 CEST] <furq> i meant the non-split command [13:26:47 CEST] <furq> it should hopefully run quicker [13:27:28 CEST] <an3k> wow, 12 fps [13:37:24 CEST] <durandal_1707> an3k: it can be very cheap [13:39:58 CEST] <an3k> Thank you furq for your help so far :) [13:40:30 CEST] <an3k> It totally depends on what "very cheap" means but generally I'd be very interested @ durandal_1707 [14:14:54 CEST] <inna> https://i.imgur.com/3GNH4Qm.jpg [14:15:01 CEST] <inna> this is how you do it, bebeh. [15:39:08 CEST] <tuxx> hey guys.. i'm reading from stdin (a camera stream with h264 encoded video) into ffmpeg and would like to stream it to rtmp but i am getting a fairly high delay... [15:39:20 CEST] <tuxx> i pressume ffmpeg needs to read some initial frames to detect the stream settings properly which in itself causes some of the delay [15:39:36 CEST] <tuxx> raspivid -t 0 -w 960 -h 540 -fps 10 -b 500000 -hf -vf -o - | ffmpeg -i - -s 960x540 -r 25 -pix_fmt yuv420p -vcodec copy -an -f flv -metadata streamName=myStream "rtmp://live-fra.twitch.tv/app/live_237180984_imcSkvuBnkwZCWGJTxaKFG5aLMIHgY" [15:39:43 CEST] <tuxx> are there any options that i cld possibly specify in order to reduce latency? [15:40:06 CEST] <tuxx> it takes roughly 10-15 seconds for ffmpeg to start streaming, and i'm not sure if that initial lag is dropped eventually or if it propagates forever as an offset [15:56:51 CEST] <skunkworks> Hello - I have an old sony cam corder that I was able to hookup firewire to a PC. I used vlc and recorded the stream. I have an avi file but am having problems converting it. [15:58:11 CEST] <skunkworks> Duration: 00:13:48.72, start: 0.000000, bitrate: 30311 kb/s [15:58:11 CEST] <skunkworks> Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s16, 1536 kb/s [15:58:14 CEST] <skunkworks> Stream #0:1: Video: none (dv / 0x20207664), none, 720x480, 28765 kb/s, 29.96 fps, 29.96 tbr, 29.96 tbn, 29.96 tbc [15:58:17 CEST] <skunkworks> No decoder for stream #0:1, filtering impossible [15:58:19 CEST] <skunkworks> Error opening filters! [16:03:31 CEST] <skunkworks> vlc plays it.. [16:21:09 CEST] <skunkworks> This is what I tried ffmpeg -analyzeduration 2147483647 -probesize 2147483647 -i vlc-record-2019-05-28-17h01m56s-dshow___-.avi youroutput.mp4 [16:29:03 CEST] <termos> if I capture from my webcamera and stream is as DASH with `streaming 1` i'm getting the expected behaviour in chrome network tab where each 6s segment takes around 5.8s to download so it's streamed. If I use another input like some rtmp with h264 then chrome is showing each segment being fetched in ~2s. I don't understand how the input can affect this... [16:30:16 CEST] <termos> I tried to use an rtmp h264 input with only I-frames to make it similar to my camera input which only has reference frames, but it was still 2s to fetch one 6s segment. so it's no longer streaming the full segment, it just starts streaming after some time [17:44:39 CEST] <th3_v0ice> Can I safely change this flag #define AV_PTS_WRAP_IGNORE, to 1? Will this mess up some muxers or demuxers? [19:31:53 CEST] <causa-sui> DHE: sorry for repeating myself, I just don't know how to do that either... :( [20:40:08 CEST] <SixEcho> i am interested in adding some guages over video& open to using any technology per-se. any recommendations what base technology to use that are easy to integrate with ffmpeg? i'm already using several complex filters and overlaying multiple videos in my existing process. videos can be lengthy (hours), so not interested in generating 100k's of transparent overlay PNG's or somesuch. [20:50:58 CEST] <DHE> real-time generation of videos? [20:51:54 CEST] <DHE> a second overlay video may be easiest, and you can generate it using any method you like. maybe just a named pipe in RGBA format or something. [20:58:31 CEST] <bencc> I'm trying to crop mp4 and extract the first image: [20:58:32 CEST] <bencc> ffmpeg -i test.mp4 -vf "crop=620:680:300:20, select=eq(n\,0)" -q:v 1 test.png [20:59:33 CEST] <bencc> sorry. was missing a parameter [21:12:06 CEST] <SixEcho> DHE: yeah RGBA probably the simplest& [21:12:35 CEST] <SixEcho> no, not real-time videos [21:27:43 CEST] <kepstin> bencc: best way to output only one frame is to use the "-vframes 1" option, no need for select there. [22:19:38 CEST] <bencc> kepstin: thanks [22:20:05 CEST] <bencc> how can I replace white backgorund in a video with transparency? [22:22:13 CEST] <bencc> tried: [22:22:14 CEST] <bencc> ffmpeg -i test.mp4 -vf chromakey=white test.gif [22:22:21 CEST] <bencc> but it still has white background [22:24:06 CEST] <durandal_1707> why gif? [22:24:50 CEST] <bencc> I need it in powerpoint [22:24:56 CEST] <bencc> a video won't work in this case [22:31:53 CEST] <SixEcho> bencc: try increasing the similarity N with -vf chromakey=white:N to see if you can get a result& [22:32:19 CEST] <SixEcho> 0.01 to 1.0& try 0.1 [22:32:59 CEST] <bencc> trying [22:34:11 CEST] <bencc> I don't see any difference. I'm probably doing something wrong [22:34:58 CEST] <kepstin> i don't think the ffmpeg gif encoder supports transparency [22:35:20 CEST] <bencc> I see this in the terminal: No accelerated colorspace conversion found from yuva420p to bgr8. [22:35:25 CEST] <bencc> not sure if it's related [22:35:40 CEST] <bencc> maybe I need to set the chromakey color in yuv? [22:35:47 CEST] <bencc> kepstin: ok. thanks [22:36:55 CEST] <kepstin> bencc: actually it looks like it can, as long as you do a two-step encode with the 'palettegen' and 'paletteuse' filters to do the colourspace conversion to pal8 before encoding to gif [22:37:16 CEST] <durandal_1707> use filters for gif [22:37:16 CEST] <bencc> kepstin: don't know how to use it :) [22:38:08 CEST] <bencc> durandal_1707: what filters? [22:40:29 CEST] <durandal_1707> google mentioned filters [22:41:40 CEST] <TheAMM> bencc: https://ffmpeg.org/ffmpeg-filters.html#palettegen https://ffmpeg.org/ffmpeg-filters.html#paletteuse [22:41:47 CEST] <TheAMM> gosh, manuals! [23:07:28 CEST] <upgreydd> is there an option to set some decoder specific things like "log2_max_frame_num_minus4" in SPS header of h264? [23:08:50 CEST] <upgreydd> https://yumichan.net/video-processing/video-compression/explanation-of-desc… found some info here but I have no idea what to do xD [23:11:37 CEST] <SixEcho> bencc: use this -filter_complex "[0:v] chromakey=white:0.05:0, split [a][b]; [a] palettegen=reserve_transparent=on:transparency_color=white [p]; [b][p] paletteuse" [23:12:01 CEST] <SixEcho> you may not need the 0.05& but just see if you get a result [00:00:00 CEST] --- Thu May 30 2019

1 0

ffmpeg-devel.log.20190528
by burek 29 May '19

29 May '19

[03:19:50 CEST] <cone-460> ffmpeg 03Jun Zhao 07master:3ba09704fafa: doc/build_system: Document checkheaders/alltools and consistency fixes [03:19:50 CEST] <cone-460> ffmpeg 03Jun Zhao 07master:b63df9b52705: doc/encoders: Document eld_v2 option for libfdk_aac encoder. [03:19:50 CEST] <cone-460> ffmpeg 03Jun Zhao 07master:b983e71bde6c: lavfi/sr: Remove slice thread flag [03:19:50 CEST] <cone-460> ffmpeg 03Jun Zhao 07master:9b069eb14e07: lavfi/sr: Change the backend type from flags to int [08:53:50 CEST] <vtorri99978666> hello [08:54:27 CEST] <vtorri99978666> while corss compiling on linux for Windows, configure fails because libbluray is not found by pkg-config (libbluray is installed) [08:54:48 CEST] <vtorri99978666> is it possible to have a configure output (a config.log, or a verbose mode) ? [08:56:20 CEST] <vtorri99978666> i can also see that bd_open is requested with libbluray, maybe it is the reason of the failure [08:56:27 CEST] <vtorri99978666> what is bd_open ? [08:57:25 CEST] <vtorri99978666> maybe a symbol in libblueray... [08:58:01 CEST] <vtorri99978666> yes, that's it [09:01:57 CEST] <cone-071> ffmpeg 03Gyan Doshi 07master:eae251ead9e3: avformat/segment: populate empty outer stream extradata from packet [09:03:32 CEST] <vtorri99978666> bbl [11:17:07 CEST] <cone-071> ffmpeg 03Paul B Mahol 07master:b16806b09d60: avfilter/avf_avectorscope: make use of av_rescale [11:17:08 CEST] <cone-071> ffmpeg 03Paul B Mahol 07master:618f8bb0a49e: avfilter/avf_abitscope: make use of av_rescale [11:17:09 CEST] <cone-071> ffmpeg 03Paul B Mahol 07master:d2e76a1f96d7: avfilter/avf_showvolume: make use of av_rescale [11:17:10 CEST] <cone-071> ffmpeg 03Paul B Mahol 07master:cd753968976d: avfilter/avf_ahistogram: make use of av_rescale [11:17:11 CEST] <cone-071> ffmpeg 03Paul B Mahol 07master:62c8707e2ac1: avfilter/avf_showwaves: make use of av_rescale_q [11:17:12 CEST] <cone-071> ffmpeg 03Paul B Mahol 07master:819ed1df94df: avfilter/avf_aphasemeter: make use of av_rescale [18:06:42 CEST] <j-b> Does anyone know why the SSE code depends on the MMX one? [18:08:34 CEST] <jamrial> you mean configure dependency? [18:10:49 CEST] <j-b> yes [18:11:02 CEST] <jamrial> that's by design, afaik. an instruction set enables all the previous ones as well [18:11:15 CEST] <jamrial> so you can't build ffmpeg with ssse3 but no sse2, and such [18:11:20 CEST] <kurosu> also, maybe, the old constants, stored in a C file, to reduce symbol & data duplication ? [18:14:02 CEST] <kurosu> also, afaik, it's indeed rare to find a CPU with some set that doesn't have ones (amd 3now various sets maybe being an exception) older that said set [18:33:54 CEST] <Lynne> we still have fma4 assembly, we can save some kilobytes if we remove it (no fma4-only function exists, they're all templated) [18:35:09 CEST] <Lynne> its only in avf_showcqt and lavr though [18:35:48 CEST] <durandal11707> do not make showcqt slow [18:39:23 CEST] <jamrial> why would we remove fma4? bulldozer based cpus are still pretty widespread [18:45:49 CEST] <Lynne> doesn't every amd cpu with fma4 also support fma3? if the performance of both is the same then there's no reason to carry both [18:54:53 CEST] <jamrial> piledriver, steamroller and excavator do, bulldozer does not [18:55:45 CEST] <jamrial> but in any case, they are all slow when using ymm registers. that's why all the fma4 functions were written using xmm registers [18:56:06 CEST] <jamrial> none of the fma3 functions are enabled for those cpus, as they use ymm registers [18:58:13 CEST] <Lynne> oh, makes sense, I thought amd included fma3 when intel refused to use their fma4 encoding [19:01:34 CEST] <jamrial> they did during the first refresh, with piledriver [22:02:42 CEST] <mkver> Is there actually an easy way to find out which fate tests might be affected by changes to a certain file? [22:05:12 CEST] <nevcairiel> not necessarily [22:05:33 CEST] <nevcairiel> many components have direct tests of course, which are easily identifiable [22:05:40 CEST] <nevcairiel> but they may also be used in other tests [22:09:18 CEST] <mkver> Yeah, the easy tests are of course easily identifiable. It's the other tests that worry me. [22:10:38 CEST] <mkver> E.g. for my matroska demuxer patches I changed the Matroska demuxer to always return -1 on init and the tests that were broken by this were the tests that I am interested in. [22:22:52 CEST] <nevcairiel> run full fate [22:22:53 CEST] <nevcairiel> :) [22:23:14 CEST] <nevcairiel> one should do that once before sending patches anyhow, in my experience [22:23:17 CEST] <nevcairiel> too many unknowns [22:26:55 CEST] <mkver> I did it after certain of the big patches; but doing it for every patch in a patchset? That's quite a lot. The other patches were checked with the list of tests known to be affected by the patches in question. [22:30:22 CEST] <jamrial> what you did by making the demuxer always return -1 is fine. the tests that fail after that are those that use said demuxer. every other test should be unaffected [00:00:00 CEST] --- Wed May 29 2019

1 0

ffmpeg.log.20190528
by burek 29 May '19

29 May '19

[00:07:28 CEST] <furq> kevinnn: just save it as .h264 then [00:26:17 CEST] <victorqueiroz> Is FFMPEG suitable for a game in terms of performance? [00:26:38 CEST] <kepstin> victorqueiroz: need more information. what do you plan to use ffmpeg for? [00:26:42 CEST] <JEEB> depends on the exact modules, but various common video/audio formats are plenty fast enough [00:26:51 CEST] <JEEB> less common ones are often not optimized for speed :P [00:27:00 CEST] <kepstin> ffmpeg has probably the best software h264 and vp8/9 decoders, fwiw. [00:27:48 CEST] <victorqueiroz> JEEB: I was just using libjpeg to decode jpeg images and found myself writing codecs and abstractions so I thought: Hm, maybe I could use ffmpeg to do that. I don't like using stb implementations, if you ask me [00:28:23 CEST] <JEEB> STB (?) [00:28:30 CEST] <JEEB> for me that is "set-top box" [00:28:42 CEST] <victorqueiroz> JEEB: https://github.com/nothings/stb [00:28:50 CEST] <victorqueiroz> JEEB: is that a vim shortcut? [00:29:49 CEST] <kepstin> no, just an acronym used in the video world [00:30:07 CEST] <JEEB> a set top box is one of those things you get fed by your internet/cable companies :P [00:30:10 CEST] <JEEB> the plastique boxes [00:30:31 CEST] <kepstin> if you're encoding video for a stb, that means you're encoding it for broadcast tv, to be decoded by a box that (in the case of crt tvs) traditionally sat on top of the tv [00:30:46 CEST] <kepstin> they don't really fit on top of tvs any more :( [00:31:22 CEST] <JEEB> victorqueiroz: anyways, take a look at the transcoding and transcoding_aac examples for example [00:31:35 CEST] <JEEB> they do go a bit different way by including stuff that you probably don't need [00:31:38 CEST] <JEEB> like encoding [00:31:43 CEST] <JEEB> but it's a general overview of the API [00:31:56 CEST] <kepstin> victorqueiroz: ffmpeg is mostly designed for use with audio/video media rather than still images, it might be a bit awkward to use for only still images. [00:32:09 CEST] <JEEB> libavformat for reading/writing into containers, libavcodec to decode and encode packets into raw frames [00:32:12 CEST] <JEEB> etc [00:32:26 CEST] <JEEB> for actual playback there are higher level libraries such as libvlc or libmpv [00:35:42 CEST] <victorqueiroz> JEEB: That's very nice guys. Thank you for explaining [00:35:51 CEST] <victorqueiroz> I'll just stick to libjpeg-turbo for now, then [00:43:59 CEST] <q66> please don't use jpeg for textures in games [00:45:14 CEST] <CounterPillow> There's so many formats that are better than JPEG [00:45:22 CEST] <q66> for textures, always [00:45:38 CEST] <q66> either keep them uncompressed or use something that GPUs can crunch like ASTC/ETC or even S3TC [00:46:28 CEST] <q66> jpeg will make them look like ass for no benefit other than pure savings of storage space, and it seriously messes up things like normalmaps [00:49:34 CEST] <Atlenohen> Hey guys, is MPEG-2 video codec any good for lossless, the CPU resources are a factor, so if it's a lot easier on the CPU than x264 it's good, but would it be any better over x264 for same resources? [00:50:00 CEST] <JEEB> x264 is an encoder, fyi [00:50:04 CEST] <JEEB> the format is called AVC or H.264 [00:50:10 CEST] <JEEB> also x264 can be freaking fast [00:50:30 CEST] <JEEB> unlikely that an MPEG-2 encoder would be faster than x264 with preset ultrafast :P [00:55:07 CEST] <JEEB> and for decoding I remember decoding SD encodes that were created with more or less what x264 --tune fastdecode is now with the original 733MHz Xbox [00:56:08 CEST] <JEEB> (it was more or less a pentium 3 era celeron) [00:56:14 CEST] <another> i don't think mpeg2 has a lossless mode [00:56:24 CEST] <JEEB> and yea, I don't remember that either [00:56:50 CEST] <another> at least not in ffmpegs implementation [01:07:50 CEST] <CounterPillow> If you want fast lossless, you can do huffyuv. If you want small lossless, you can do ffv1 or H.264 in lossless mode. [01:09:00 CEST] <CounterPillow> also consider that with x264, the speed profiles still apply, so lossless ultrafast is probably still gonna be better than huffyuv for most cases [01:09:08 CEST] <another> afaik ffvhuff was the faster one [01:09:28 CEST] <another> *faster than huffyuv [01:09:34 CEST] <CounterPillow> ah, cool [01:10:21 CEST] <another> at least it supports a lot more pixel formats [01:10:47 CEST] <CounterPillow> At any rate, at certain resolutions your bigger concern with fast lossless codecs is whether your disk can keep up [01:28:08 CEST] <Atlenohen> Good suggestions guys [01:28:55 CEST] <Atlenohen> except that MPEG-TS has limited codec support ... it's not strict but it's a bonus, I need something lossless that can go into MPEG-TS [01:31:42 CEST] <furq> you're pretty much stuck with x264 then [01:38:30 CEST] <Atlenohen> Allright. Also double checking, is it true that most video today is VFR and that it just appears as CFR ? [01:43:28 CEST] <Atlenohen> Like in MKV, and the ones that support VFR [01:47:34 CEST] <Atlenohen> Oh and, would VFR/CFR and time stuff change according to what codec is uses, or it has no effect, it's all in the container ? [01:49:07 CEST] <Atlenohen> I see 1/90000 for MPEG-TS which seems a huge difference to MKV's 1/1000 [01:50:05 CEST] <Atlenohen> That makes MPEG-TS better right? [01:54:20 CEST] <kepstin> Atlenohen: in practice, the 1/1000s precision used by most tools with mkv is fine [01:56:45 CEST] <kepstin> for typical current video framerates [01:58:59 CEST] <Atlenohen> Also I was trying to test whether a video is CFR or VFR, but it takes time to manually see each frame in ffprobe, is there any automated way of seeing the timecode changes that would indicate CFR? I remember it now but forgot [01:59:24 CEST] <kepstin> Atlenohen: anyways, most common current containers store each frame with a timestamp value, allow arbitrary jumps in the timestamp value between frames, and index based on time. [02:06:07 CEST] <Atlenohen> Here's .ts file https://pastebin.com/VzJUvXWN [02:10:32 CEST] <Atlenohen> kepstin: I've got a number of files, configurations, codecs, containers to test, I'll really need some kind of an utlitiy which analyzes everything about time codes and PTS and whatever, and produces a report [02:11:02 CEST] <Atlenohen> It's no way it's doable manually going through each multi 100 MB or GB (lossless) file [02:11:25 CEST] <Atlenohen> At least incredibly impractical for me to even attempt it [02:38:18 CEST] <Atlenohen> I got something so AVI + MPEG4 starts at: pkt_pts_time=0.000000 and goes to 0.066667 and 0.083333 [02:39:37 CEST] <Atlenohen> while MPEG-TS and x264 starts at: 0.016667 and goes to 0.033333, 0.050000, 0.066667, 0.083333 [02:43:46 CEST] <Atlenohen> that's a precision diff, but how to see whether one is constant frame rate or not [02:44:23 CEST] <Atlenohen> pkt_duration_time=0.016667 by that number' [02:44:24 CEST] <Atlenohen> = [02:44:28 CEST] <Atlenohen> ? [04:31:38 CEST] <kepstin> Atlenohen: if the pkt_duration_time varies by no more than ±0.002 or so between frames, you can probably treat the video as cfr. errors smaller than that are likely due to rounding when converting between timebases. [04:32:41 CEST] <kepstin> would want to test any given threshold against a sample of videos to make sure it works for you tho. [04:33:17 CEST] <kepstin> depends exactly what you're going to use this "cfr video" knowledge for, really. [09:36:29 CEST] <CarlFK> I have files created with -flags +ilme+ildct https://github.com/CarlFK/voctomix-outcasts/blob/master/record-timestamp.sh… [09:36:50 CEST] <CarlFK> I want to deinterlace them now. [09:37:02 CEST] <CarlFK> this made nice video, but no audio: [09:37:16 CEST] <CarlFK> ffmpeg -i 14_58_47.tsi -map 0:v -c:v:0 mpeg2video -pix_fmt:v:0 yuv420p -qscale:v:0 2 -qmin:v:0 2 -qmax:v:0 7 -keyint_min 0 -bf:0 0 -g:0 0 -deinterlace -acodec copy -f mpegts 14_58_47.tsp [09:39:36 CEST] <CarlFK> do I need -map 0:a -c:a:0 [09:45:28 CEST] <durandal11707> why are you using -deinterlace ? [09:47:31 CEST] <CarlFK> to deinterlace [09:47:58 CEST] <durandal11707> that is bad and wrong way, search google for better ways [09:48:16 CEST] <CarlFK> will it fix my audio problem ? ;) [09:48:20 CEST] <JEEB> hint: the yadif video filter is mostly what you want [09:48:49 CEST] <JEEB> CarlFK: and yes if you start mapping manually you need to map the audio too :) [09:49:09 CEST] <JEEB> you current only map the video track(s) from the input [09:54:09 CEST] <CarlFK> google says replace -deinterlace with -vf yadif=3:1,mcdeint=2:1 [09:55:10 CEST] <JEEB> don't use the numeric values :< [09:55:14 CEST] <JEEB> magical values = unreadable [09:55:20 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html [09:55:25 CEST] <JEEB> see the options for yadif here [09:57:06 CEST] <durandal11707> CarlFK: your audio is which codec? [09:58:11 CEST] <CarlFK> durandal11707: I wanted to copy it. it was created with -map 0:a -c:a:0 mp2 -b:a:0 192k -ac:a:0 2 -ar:a:0 48000 \ [09:58:58 CEST] <CarlFK> getting rid of the number sped it up [09:59:36 CEST] <CarlFK> looks like Ill have audio this time too: Stream #0:1[0x101](eng): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, s16p, 192 kb/s [11:01:50 CEST] <superware> after I'm calling avformat_find_stream_info for an RTSP stream, how can I get the actual mrl for each of the video/audio streams? eg. opening rtsp://...:554/CH001.sdp might open the video on rtp://...:1234, how can I get the actual video stream mrl? [11:04:19 CEST] <JEEB> not sure if that is exported [11:04:35 CEST] <JEEB> since lavf is supposed to handle that for you so that you can just read packets of data [11:04:45 CEST] <JEEB> lavf generally is on a higher abstraction level [11:17:23 CEST] <superware> JEEB: are you sure it's somehow no exposed? :| [11:17:31 CEST] <superware> not somehow exposed...? [12:05:37 CEST] <JEEB> superware: you'd have to look into it but I would bet it'd be a lower abstraction layer thing [12:32:44 CEST] <superware> JEEB: managed per AVStream? [12:46:07 CEST] <JEEB> superware: no, I mean something that a normal API user would not require to know :P [13:19:36 CEST] <superware> ok, thanks [22:43:08 CEST] <Mysterytrain> when you see, subrip, in a subtitle stream, what does that mean? [22:55:42 CEST] <c_14> it's a subtitle format [23:04:22 CEST] <causa-sui> I have been using ffmpeg to make short clips out of larger video files. With one, I want to make an "eternal loop" i.e. play the clip, then seamlessly play the clip in reverse back to the beginning. Would anyone be kind enough to help me figure out how? [23:18:32 CEST] <DHE> reverse is tricky. you'll probably want to turn the movie into individual frames (png, jpegs, whatever), reverse the filenames, and then re-encode a backwards video movie from that [23:26:27 CEST] <c_14> there is the reverse filter [23:26:36 CEST] <c_14> it'll just use a lot of memory depending on the size of the video [23:44:58 CEST] <bencc> I have a video with animated cartoon over fixed background [23:45:15 CEST] <bencc> is there a way to crop the cartoon and hide the background? [23:57:22 CEST] <TheAMM> bencc: https://ffmpeg.org/ffmpeg-filters.html#crop [23:57:51 CEST] <TheAMM> I wish you luck with your youtube anime rips [23:59:01 CEST] <causa-sui> c_14: not a big video. can I do this in one operation or would you make a normal + reversed video, and then conjoin them after? [00:00:00 CEST] --- Wed May 29 2019

1 0

ffmpeg-devel.log.20190527
by burek 28 May '19

28 May '19

[00:35:22 CEST] <cone-960> ffmpeg 03Antonin Gouzer 07master:3da8d04c18fe: fftools/ffprobe: Add S12M Timecode output as side data (such as SEI TC) [10:14:05 CEST] <j-b> 'morning [17:40:12 CEST] <cone-708> ffmpeg 03Paul B Mahol 07master:293489d8355a: avfilter/af_superequalizer: switch to activate [17:56:06 CEST] <cone-708> ffmpeg 03James Almer 07master:0e07b767c86c: avcodec/libdav1d: export level from the Sequence Header [17:56:07 CEST] <cone-708> ffmpeg 03James Almer 07master:254da41531aa: avcodec/libdav1d: assert Dav1dPicture allocator_data is set before referencing its data [18:03:38 CEST] <cone-708> ffmpeg 03Werner Robitza 07master:7458fa119c90: doc/swscaler: explain default Lanczos parameter [18:22:15 CEST] <cone-708> ffmpeg 03James Almer 07master:f78172b29ae7: avcodec/libdav1d: add support for RGB streams [18:46:39 CEST] <cone-708> ffmpeg 03Paul B Mahol 07master:5ddaedcaec39: avfilter/avf_showvolume: switch to activate [19:04:10 CEST] <cone-708> ffmpeg 03Michael Niedermayer 07master:e6f4d5dc384a: avcodec/ffv1dec_template: Optimize common case in run mode [19:04:11 CEST] <cone-708> ffmpeg 03Michael Niedermayer 07master:8eecf761a65b: avcodec/truemotion2: Fix several integer overflows in tm2_update_block() [19:04:12 CEST] <cone-708> ffmpeg 03Michael Niedermayer 07master:90db25a16e5a: avcodec/diracdec: Check for arith decoder errors in dirac_unpack_block_motion_data() [19:04:13 CEST] <cone-708> ffmpeg 03Michael Niedermayer 07master:bf3ee6a13053: avformat/mp3enc: Avoid SEEK_END as it is unsupported [20:16:43 CEST] <Lynne> svt-av1's getting a decoder as well [20:21:59 CEST] <Lynne> "2. Speed of decoder should be comparable to that in libaom on x86 architecture." <- "ii. Success Criteria Detail:" [20:40:03 CEST] <nevcairiel> and dav1d is significantly faster then that, so .. its useless? :D [20:40:24 CEST] <JEEB> weird stuff [20:41:11 CEST] <JEEB> but I guess corporate requirement lists are like that [20:51:34 CEST] <j-b> Lynne: where? [20:51:47 CEST] <JEEB> https://github.com/OpenVisualCloud/SVT-AV1/commit/c7b108ad518b2f223fa7d56c3… [20:55:51 CEST] <j-b> ah yes, that one [21:00:37 CEST] <kierank> 12k line diff [21:00:38 CEST] <kierank> noice [21:02:27 CEST] <JEEB> kierank: SVT things tend to be code dump commits [21:03:28 CEST] <jamrial> with all the issues that brings. a similar dump introduced segfauls in some encoding scenarios [21:03:34 CEST] <jamrial> good luck finding what caused it :p [21:04:09 CEST] <JEEB> yup [00:00:00 CEST] --- Tue May 28 2019

1 0

ffmpeg.log.20190527
by burek 28 May '19

28 May '19

[00:27:53 CEST] CTCP VERSION: from snap1 (snap1!ashiudo@unaffiliated/damdai) to #ffmpeg [00:27:53 CEST] CTCP reply VERSION: from irdr (irdr!irdr(a)137.204.76.34.bc.googleusercontent.com) to #ffmpeg [00:39:10 CEST] <snap1> satoshi2 hello [00:40:39 CEST] <satoshi2> hello, why [00:41:08 CEST] <snap1> why what [00:42:32 CEST] <satoshi2> respect my privacy nsa [00:44:00 CEST] <snap1> what privacy? [00:44:36 CEST] <klaxa> that's exactly what nsa would ask, but smirkly [00:47:05 CEST] <Atlenohen> Hello [00:47:51 CEST] <Atlenohen> So I have a mkv and mpegts files i'd like to check whether they're variable framerate or constant, can I do that with ffprobe quickly? [00:50:55 CEST] <DHE> not consistently. youd have to read the whole file to be sure. [00:51:04 CEST] <DHE> and that's not "quickly" [00:55:12 CEST] <Atlenohen> What about in Adobe Premiere, which supports VFR now [01:02:43 CEST] <Atlenohen> Timeline should show it if it supports right ... [01:47:56 CEST] <snap1> DHE can you tell the difference between x264 video and nvenc video? [02:01:17 CEST] <DHE> ignoring misdirected question [02:18:48 CEST] <CounterPillow> lol [02:37:41 CEST] <Atlenohen> DHE: I got confused a bit, just double checking, which one is more precise, MKV 1/1000 or MPEG-TS 1/90000 [02:42:03 CEST] <DHE> 90,000 is the bigger number, so it's more precise [02:42:40 CEST] <CounterPillow> more like 1/90000 is the smaller number so it's more precise [02:54:22 CEST] <Numline1> Apparently miniDLNA has been dead for almost 10 years [02:54:37 CEST] <Numline1> That's cute, especially since it's still included as a go-to in ubuntu/debian :O [03:58:42 CEST] <radius> hello [03:59:01 CEST] <radius> which output pixel formats can be used for the png encoder? [04:06:15 CEST] <klaxa> > Supported pixel formats: rgb24 rgba rgb48be rgba64be pal8 gray ya8 gray16be ya16be monob [04:06:25 CEST] <klaxa> you can get that with: ffmpeg -help encoder=png [04:06:46 CEST] <radius> oh thanks a lot much appreciated! [04:06:46 CEST] <klaxa> that will list all kinds of information about the png encoder including supported pixel formats [08:08:07 CEST] <sazawal> Hello. What is an appropriate command/software to split an mkv between two keyframes? I guess, I have to re-encode the whole video before splitting it, can I use Handbrake for this? Avidemux works for me, but I am not sure if I am losing some quality. I also have a bad experience of early versions of avidemux where splitting gave me green/gray endings. [09:34:49 CEST] <pink_mist> sazawal: if you're re-encoding you _will_ lose quality unless you do a lossless encoding, which will be HUUUUUUUUUUUUUUUUUGE [09:36:52 CEST] <sazawal> pink_mist, Hi. So, is there another way for splitting between the keyframes? Say, is it possible to generate more keyframes between two keyframes? [09:37:30 CEST] <sazawal> MKVCutter seems to do this job by re-encoding only the part where the splitting is taking place, but I dont have access to windows at the moment. What do you think about Avidemux splitting? [09:38:17 CEST] <pink_mist> I think the only tool that works for this is MKVCutter, sorry [09:38:24 CEST] <pink_mist> at least that I've heard of [09:38:43 CEST] <pink_mist> ffmpeg specifically doesn't deal with it, and since HandBrake uses ffmpeg, it doesn't either [09:39:02 CEST] <pink_mist> I haveto admit I have no experience with avidemux though, so I can't really comment on that [09:39:42 CEST] <sazawal> pink_mist, I see. Thanks anyway. [19:49:25 CEST] <nitrxgen> -vf "transpose=2" sometimes doesn't rotate my video, usually from my phone [19:50:27 CEST] <nitrxgen> original video and output video are same orientation [19:51:09 CEST] <nitrxgen> and strangely neither does transpose=3 but it does flip it! just not rotate it, any advice? [21:07:04 CEST] <upgreydd> Hello. Guys quick question, Is there an option to force codec time base? For example 1/60 [21:08:04 CEST] <upgreydd> I've tried with `-time_base 1/30` parameter, but I'm still getting "codec_time_base=2/119" so it's almost 1/60 [21:11:25 CEST] <upgreydd> JEEB: friend :D [23:03:42 CEST] <Atlenohen> Hello [23:03:52 CEST] <Atlenohen> So webm_dash_manifest isn't same as webm in ffmpeg? [23:04:07 CEST] <Atlenohen> If I encode with "webm" i won't be able to decode it ? [23:04:20 CEST] <Atlenohen> unless I use the dash manifest which has both? [23:05:48 CEST] <CounterPillow> Does anyone have some rough performance figures for software decoding 10-bit H.264 on modern phone SoCs [23:06:31 CEST] <CounterPillow> Atlenohen: "which has both" what? [23:06:44 CEST] <JEEB> Atlenohen: I think the webm dash thing is a really weird thing that only outputs the manifest [23:06:47 CEST] <JEEB> although I'm not sure [23:06:59 CEST] <JEEB> google added it and it was taken in for reasons (?) [23:07:01 CEST] <Atlenohen> CounterPillow: If the internal doc is right .. [23:07:05 CEST] <CounterPillow> both what [23:07:24 CEST] <Atlenohen> ffmpeg.exe -formats: shows "webm" as having only an encoder [23:07:32 CEST] <JEEB> yes [23:07:37 CEST] <Atlenohen> but webm_dash_manifest as both [23:07:44 CEST] <c_14> Atlenohen: it's listed under matroska,webm [23:07:52 CEST] <c_14> the decoder, that is [23:07:57 CEST] <CounterPillow> webm is a subset of matroska [23:08:02 CEST] <Atlenohen> oh sure ... yeah [23:08:08 CEST] <Atlenohen> yeah it's there then. [23:08:29 CEST] <Atlenohen> I did knew that I was just confused a bit [23:08:29 CEST] <JEEB> CounterPillow: my 2014 oneplus one plays 720p24/1.001 10bit H.264 real time [23:08:43 CEST] <JEEB> but I haven't benchmarked it more than that [23:08:44 CEST] <CounterPillow> JEEB: thanks [23:08:55 CEST] <JEEB> I think the OPO was either a 3 or 4 core thing [23:08:58 CEST] <JEEB> not sure [23:09:02 CEST] <JEEB> possibly dual? [23:09:06 CEST] <JEEB> (Ž4@) [23:09:32 CEST] <JEEB> > 2.5 GHz (2457 MHz) quad-core Krait 400 [23:09:40 CEST] <JEEB> gonna bet you it was not on that rate for long [23:37:25 CEST] <kepstin> should be fine as long as you always watch videos inside a freezer. [23:46:41 CEST] <kevinnn> Hi all! I wanted to create a raw h264 file from an mp4 file I had. For my particular use case I needed to use a special h264 format. This is the command that was suggested to me: ffmpeg -y -i sourceFile -r 30000/1001 -b:a 2M -bt 4M -vcodec libx264 -pass 1 -coder 0 -bf 0 -flags -loop -wpredp 0 -an targetFile.mp4 [23:46:54 CEST] <kevinnn> Unfortunately this produced a file that vlc struggled to play [23:47:00 CEST] <kevinnn> any reason why that might be? [23:47:27 CEST] <BtbN> Why "-pass 1" when you're not doing a second pass? [23:47:51 CEST] <kepstin> that "-b:a" seems incorrect, too, maybe should be "-b:v" to set video bitrate? [23:47:53 CEST] <kevinnn> BtbN: to be honest I don't know... [23:48:26 CEST] <kepstin> kevinnn: how about we start from the start again, what are the requirements of your particular use case? [23:48:37 CEST] <BtbN> Also, that's creating an mp4 file, not raw h264. You generally never want raw h264 though [23:49:06 CEST] <kevinnn> "does not support weighted prediction for P-frames and CABAC entropy encoding" [23:49:15 CEST] <kevinnn> these are the requirements [23:49:32 CEST] <kevinnn> and I am fairly positive I want a raw h264 file [23:50:32 CEST] <BtbN> Why? It has no FPS information or anything [23:51:08 CEST] <kevinnn> BtbN: well I want to transmit NAL unit by NAL unit [23:51:10 CEST] <kevinnn> for streaming [23:51:41 CEST] <BtbN> So the metadata like fps and timestamps is provided elseway? [23:52:13 CEST] <kevinnn> yes that is right [00:00:00 CEST] --- Tue May 28 2019

1 0

ffmpeg-devel.log.20190526
by burek 27 May '19

27 May '19

[02:58:04 CEST] <thardin> pross: kostya wrote about your vp4 efforts [02:58:52 CEST] <thardin> https://codecs.multimedia.cx/2019/05/vp3-vp6-the-golden-frame-age-of-duck-c… [05:10:37 CEST] <pross> thardin: hey cool [13:08:45 CEST] <cone-851> ffmpeg 03Derek Buitenhuis 07master:80757bed89c3: avcodec/libx265: Support full range videos [14:44:21 CEST] <cone-851> ffmpeg 03Paul B Mahol 07master:a9fa6b8e025c: swresample/swresample: check for invalid sample rates [16:44:06 CEST] <durandal_1707> hi! [17:14:54 CEST] <cone-851> ffmpeg 03Paul B Mahol 07master:fc0de1c04be4: avfilter/avf_showfreqs: switch to activate [17:54:20 CEST] <kierank> durandal_1707: you should write in rust [21:05:33 CEST] <cone-150> ffmpeg 03Shiyou Yin 07master:6b67daa326f6: avcodec/mips: [loongson] fix mpeg4 decoding error on loongson platform. [23:06:09 CEST] Action: InTheWings looking for AC-4 samples (isobmff preferred) [23:06:20 CEST] <JEEB> DASH-IF? [23:06:36 CEST] <InTheWings> If that's Living Room 720p, it's not correct [23:06:45 CEST] <InTheWings> at least, it does not match the ETSI spec [23:06:58 CEST] <InTheWings> dsi version being 0 [23:06:59 CEST] <JEEB> not sure which it is, but I just remember the DASH-IF sample collection having AC-4 [23:07:02 CEST] <JEEB> :< [23:07:05 CEST] <JEEB> but too bad if it's derp'd [23:07:09 CEST] <InTheWings> that's this one [23:07:29 CEST] <JEEB> http://testassets.dashif.org/#feature/details/586fb3879ae9045678eab593 [23:07:36 CEST] <JEEB> this btw [23:08:32 CEST] <Lynne> https://0x0.st/zAdN.ac4 https://0x0.st/zAdq.mp4 <- these were 2 of the used to write the yet-unmerged decoder [23:09:43 CEST] <InTheWings> Lynne: okay so there's an issue also there [23:10:21 CEST] <InTheWings> E.5.1 AC4SpecificBox [23:10:35 CEST] <InTheWings> ie dac4 [23:10:53 CEST] <InTheWings> first 3 bits are ac4_dsi_version; [23:11:09 CEST] <InTheWings> This field indicates the version of the DSI. For a DSI that conforms to the present document, the ac4_dsi_version field shall be set to '001'. [23:11:31 CEST] <InTheWings> all isobmff have 0 on first bytet [23:12:46 CEST] <Lynne> so they're improperly contained in mp4? [23:12:51 CEST] <JEEB> yea [23:15:01 CEST] <InTheWings> hmm.. [23:15:09 CEST] <InTheWings> 2018 spec doesn't says 001 [23:15:26 CEST] <JEEB> funky [23:17:43 CEST] <durandal11707> InTheWings: you are wrong [23:17:47 CEST] <InTheWings> lol, Part 1 of the spec says 000 [23:18:35 CEST] <InTheWings> durandal11707: possible [23:18:49 CEST] <InTheWings> but the 2015 02 spec says 001 [23:22:41 CEST] <durandal11707> you are reading most significant or least significant bits first? [23:23:20 CEST] <InTheWings> most [23:23:57 CEST] <InTheWings> so the 1 has been removed from part 02 in 2018 revision [23:25:00 CEST] <durandal11707> the mp4 stuff is not used by decoder at all [23:26:03 CEST] <InTheWings> But when you have 2 part of the spec defining the really same AC4SpecificBox without the same values... [23:26:22 CEST] <InTheWings> Part 2 still says to set it to 1 on encoding [23:26:38 CEST] <durandal11707> isnt part about object audio? [23:26:53 CEST] <InTheWings> no idea [23:27:06 CEST] <InTheWings> AC4SpecificBox should have only one def [23:32:52 CEST] <InTheWings> okay seems they duplicated the definitions for a v0 & a v1 [23:33:08 CEST] <durandal11707> part 1 is for normal audio, part 2 is for object audio [23:34:31 CEST] <durandal11707> iirc it depends also on bitstream version [23:34:53 CEST] <durandal11707> there is 0, 1 and 2 iirc [00:00:00 CEST] --- Mon May 27 2019

1 0

ffmpeg.log.20190526
by burek 27 May '19

27 May '19

[00:14:01 CEST] <frubsen> hey, anyone here know much about ffmpeg and decklink? [08:41:44 CEST] <Trunk_> should i use CBR/VBR/ABR/CRF [08:43:49 CEST] <upgreydd> Trunk_: whats thw question? [08:46:41 CEST] <Trunk_> should i use CBR/VBR/ABR/CRF [08:46:45 CEST] <Trunk_> that's my question [08:49:50 CEST] <upgreydd> Trunk_: it depends on usecase and what you're trying to reach [08:51:02 CEST] <Trunk_> recoding a online chess game [08:51:14 CEST] <Trunk_> using 15fps [11:42:35 CEST] <upgreydd> log2_max_frame_num_minus4 < how to set this? [12:03:31 CEST] <upgreydd> is there an option to export all settings from h264 file (br, h264 specific settings etc.) and use with another file? [12:04:02 CEST] <TheAMM> I don't think so [12:04:55 CEST] <TheAMM> AFAIK you can use mediainfo to export the x264 settings and use them [12:05:22 CEST] <TheAMM> I don't think ffmpeg/ffprobe has any way to show those [12:06:10 CEST] <upgreydd> TheAMM: thanks. do you know meybe how to set some custom settings in libx264 like log2_max_frame_num_minus4 or bit_rate_scale ? [12:06:47 CEST] <TheAMM> Dunno about that option, but -x264-params is a thing [12:07:08 CEST] <furq> that'll only work if it's x264 and it has the SEI intact [12:07:14 CEST] <furq> and also some options contain colons which break with x264-params [12:07:28 CEST] <TheAMM> https://ffmpeg.org/ffmpeg-codecs.html#libx264_002c-libx264rgb, at the bottom [12:24:21 CEST] <Lyberta> hi, I have hdr video (rec.2020 10bit) and want to extract frames from it, I want to keep them in HDR, it looks like my only options are OpenEXR and maybe JEPEG 2000, can ffmpeg do that? I've tried JPEG 2000 export and it produced very dark colors [12:38:26 CEST] <JEEB> Lyberta: what is your definition of "extracting frames"? [12:39:18 CEST] <JEEB> because you could just write out raw YCbCr into Y4M or so. it will lose the colorspace metadata, but it will give you the exact decoded YCbCr image [12:39:34 CEST] <JEEB> also do note, rec 2020 only is the colorspace, the actual HDR part is the transfer function [12:39:43 CEST] <JEEB> which is usually one of the things defined in rec 2100 [12:39:46 CEST] <JEEB> either HLG or PQ [12:46:12 CEST] <snap1> what will create smaller file 720p constant whole black screen or 720p constant whole white screen [12:50:35 CEST] <Lyberta> JEEB, VLC says ST2084 [12:50:43 CEST] <JEEB> that is PQ [12:51:03 CEST] <JEEB> ffprobe -v verbose FILE would also tell it most likely [12:51:57 CEST] <Lyberta> JEEB, Stream #0:0: Video: hevc (Main 10), 1 reference frame, yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default) [12:52:03 CEST] <JEEB> yup [12:52:23 CEST] <JEEB> so TV range, BT.2020 non-constant luminance, bt.2020 and SMPTE ST.2084 transfer function [12:52:40 CEST] <Lyberta> JEEB, so I want frames as individual raster image files [12:53:19 CEST] <JEEB> at this point the question becomes what do you want to open them with? [12:53:30 CEST] <JEEB> that would define what you want to utilize as your output [12:53:56 CEST] <JEEB> and what are your requirements for what is the definition of "extracting frames" [12:54:10 CEST] <JEEB> as in, do you want just the decoded YCbCr? or do you want RGB with PQ? or what [12:55:32 CEST] <Lyberta> JEEB, can image viewers open YCbCr? I mean for LDR I could just export to PNG and be done with it, but here I don't want to lose data [12:56:27 CEST] <JEEB> well JPEG when decoded in 99% of all cases is YCbCr, so on some level they should. now the problem is what do your image viewers actually open [12:56:52 CEST] <Lyberta> JEEB, say, GIMP [12:56:59 CEST] <JEEB> I have no idea, sorry [12:57:06 CEST] <furq> tiff will store raw yuv [12:57:12 CEST] <JEEB> you will have to ask GIMP people regarding what to do with your PQ [12:57:31 CEST] <JEEB> because it all depends on if your thing that you will be opening stuff with will support PQ/BT.2020 [12:57:53 CEST] <JEEB> and that then defines if you want YCbCr or converted to RGB or whatever [12:58:01 CEST] <JEEB> (both still in PQ) [12:58:23 CEST] <JEEB> if none of your image things support PQ then you will have to figure out what colorspaces for HDR they actually do support [12:58:37 CEST] <JEEB> s/colorspaces/transfer functions/ [12:59:25 CEST] <JEEB> (and colorspaces in general) [12:59:33 CEST] <Lyberta> JEEB, ok, so what format can store YCbCr + PQ? [12:59:59 CEST] <JEEB> anything that lets you feed raw YCbCr into it. metadata is a separate piece of a mess of course [13:00:05 CEST] <JEEB> but that way your data should be unchanged [13:00:18 CEST] <JEEB> raw YCbCr data, Y4M, and as furq noted TIFF seems to support raw YCbCr? [13:00:33 CEST] <furq> maybe not 10-bit [13:00:49 CEST] <furq> lossless webp should work for 8-bit as well [13:01:01 CEST] <JEEB> well we're dealing with PQ content so 8bit isn't gonna fly [13:01:03 CEST] <furq> but support for that is pretty patchy [13:01:27 CEST] <JEEB> Lyberta: so yes, your output from FFmpeg will 100% be defined by what your stuff can support as input [13:01:33 CEST] <Lyberta> ffmpeg refused to encode into OpenEXR :( and GIMP supports opening it [13:01:50 CEST] <JEEB> what's the colorspace in OpenEXR? [13:02:17 CEST] <JEEB> IIRC it was RGB (or XYZ), so some sort of conversion has to take place [13:04:11 CEST] <Lyberta> JEEB, it looks like it allows specifying reference colors manually in the file [13:06:52 CEST] <JEEB> seems like we only have a decoder for openexr [13:07:27 CEST] <JEEB> so you can *decode* OpenEXR images from... mp4 [13:07:31 CEST] <JEEB> (or mov) [13:07:41 CEST] <JEEB> but not write them :P [13:07:47 CEST] <furq> so apparently the tiff encoder doesn't do high bit depth yuv but it is technically supported [13:07:52 CEST] <furq> although you need to pad it to 16-bit [13:08:13 CEST] <furq> if ffmpeg is out then i guess openexr is easier anyway [13:10:17 CEST] <JEEB> somehow at this point it feels as if exporting one frame as raw YCbCr from FFmpeg (keeping in mind its colorspace and transfer function), and checking out if anything takes that in with the colorspace/trc metadata and is able to write something that you need :P [13:10:38 CEST] <JEEB> although I'd really, really recommend looking up what things are actually supported properly by teh applications you plan on using [13:11:03 CEST] <JEEB> because it sucks hard when you go through a workflow and seemingly have something that should contain the data you require [13:11:10 CEST] <Lyberta> JEEB, well, it has to be free software so.... GIMP seems to be the swiss army knife [13:11:11 CEST] <JEEB> just to find that the support on the reading side sucks [13:11:31 CEST] <JEEB> I recommend talking about it with the GIMP community then [13:11:47 CEST] <JEEB> that you have some BT.2020/PQ YCbCr content that you would like to open up [13:12:01 CEST] <JEEB> and what is the best way to open that up in GIMP [13:12:27 CEST] <JEEB> Lyberta: btw what is the idea behind this export? [13:12:39 CEST] <JEEB> I'm just wondering that if you are just going to be viewing it, you will be tone mapping anyways [13:12:46 CEST] <JEEB> (on the screen) [13:13:11 CEST] <upgreydd> JEEB: found other DoorIN sample with correct h264 headers and found differences in log2_max_frame_num_minus4 log2_max_pic_order_cnt_lsb_minus4 and other such kind options. They have lot more than I. Is there an option to set them? [13:13:52 CEST] <JEEB> upgreydd: those sound like really internal values in the stream [13:14:03 CEST] <JEEB> as in, you won't find encoder options strictly setting those [13:14:16 CEST] <JEEB> I recommend you read up their definition and if actually trying to mimic those makes sense [13:14:44 CEST] <JEEB> then if it seems like those are indeed your thing, then check x264's source code regarding setting those flags [13:14:53 CEST] <JEEB> what affects them etc [13:15:14 CEST] <JEEB> I think that's the least bad way of getting it done in case that actually makes sense as you read those fields' definition [13:15:29 CEST] <JEEB> anyways, dropping out to switch servers [13:17:56 CEST] <Lyberta> JEEB, well, video players have good colors so I assume that file contains enough info to convert to LDR automatically [13:18:21 CEST] <JEEB> yes the HEVC file has enough metadata that players that support it work [13:18:29 CEST] <JEEB> such as mpv etc [13:18:34 CEST] <JEEB> and it's not LDR, it's SDR :P [13:18:56 CEST] <JEEB> Lyberta: so basically it depends on the actual use case you have for this stuff and why you want it to be in an image viewer specifically [13:20:18 CEST] <Lyberta> JEEB, well, people market "HDR" displays so I assume I want to keep all those 10 bit and transfer function in case I get one in the future [13:21:02 CEST] <JEEB> ok, so at that point you play or view the original file with a player or viewer that supports that? [13:21:19 CEST] <Lyberta> JEEB, yes [13:21:31 CEST] <JEEB> ok, then I'm wondering what the whole export thing was about? [13:21:52 CEST] <Lyberta> JEEB, to get rid of video file and keep only frames I like [13:22:34 CEST] <JEEB> then it sounds like writing singular HEVC images in 10bit lossless mode is the least bad alternative? [13:22:46 CEST] <JEEB> that way you keep the metadata and don't need to do any colorspace conversions [13:24:12 CEST] <Lyberta> JEEB, so what container can I use? [13:24:35 CEST] <JEEB> anything sane? mp4 probably is most compatible, and matroska right after that if you like that stuff [13:25:05 CEST] <JEEB> although if you're doing lossless at that point compatibility kind of becomes less relevant since not many hw decoders support lossless anyways :P [13:25:14 CEST] <JEEB> in the best case the frames you like are random access points [13:25:23 CEST] <JEEB> and you can just -c copy those :P [13:41:07 CEST] <Lyberta> JEEB, if I export to PNG all colors are wrong, what can be the case? [13:41:22 CEST] <JEEB> the default conversion path is not optimal at all [13:41:45 CEST] <JEEB> you will have to utilize zscale and one of the tone mapping filters for that [13:41:59 CEST] <JEEB> I would recommend taking screenshots with a recent enough version of mpv or so [13:42:07 CEST] <JEEB> (preferably current git master) [13:42:12 CEST] <Lyberta> JEEB, can't I just say "use whatever is in the file"? [13:42:19 CEST] <JEEB> no [13:42:23 CEST] <Lyberta> why? [13:42:39 CEST] <JEEB> since PNG is Xbit sRGB in SDR generally [13:42:47 CEST] <JEEB> so there has to be a conversion to that [13:42:56 CEST] <JEEB> not only colorspace conversions but also tone mapping [13:43:02 CEST] <JEEB> FFmpeg doesn't unfortunately do that by default [13:43:27 CEST] <JEEB> it can do it, but it's sub-optimal due to the tonemap filter basing on older version of mpv/libplacebo functionality [13:43:44 CEST] <JEEB> then the intel opencl filter is more up-to-date but that stuff has changed again in mpv/libplacebo [13:44:23 CEST] <Lyberta> JEEB, ufffff [13:44:42 CEST] <Lyberta> ok, VLC also have wrong colors, only mpv has proper ones [13:44:55 CEST] <JEEB> yes, vlc 4 will have more libplacebo integration [13:45:52 CEST] <JEEB> screenshot-format=png and screenshot-tag-colorspace=yes in your mpv config file should give you a nice result. [13:46:03 CEST] <JEEB> also if your GPU can take it, profie=gpu-hq [13:46:05 CEST] <upgreydd> JEEB: found problem :D I need H264 annex-b :D [13:46:17 CEST] <JEEB> upgreydd: how the hell were you outputting AVCc H.264 :P [13:46:30 CEST] <JEEB> I think both samples were annex b no? [13:46:34 CEST] <JEEB> the ones you linked [13:47:06 CEST] <gvth> Hello folks; I have cut the end off a video which makes the background music stop abruptly. I would like to provide the audience a smooth experience by decreasing the volume starting at 'end minus two seconds' to the actual end gradually from 100% to 0%. Is ffmpeg capable of accomplishing that? Thanks in advance for any straightforward suggestion :) [13:47:51 CEST] <upgreydd> JEEB: my h264 without custom header starts with 00 00 00 01 67 their have 00 00 00 01 09 10 00 00 00 01 67 [13:48:30 CEST] <JEEB> upgreydd: both three and four byte start codes are Annex B [13:48:42 CEST] <JEEB> I don't remember how AUD worked but is it that? [13:48:52 CEST] <JEEB> (AUD helps parsers if I recall correctly) [13:49:37 CEST] <JEEB> you can set x264 f.ex. to use access unit delimiters [13:49:39 CEST] <upgreydd> JEEB: I was thinking 00 00 00 01 09 10 is custom but this comes from h264 [13:50:16 CEST] <JEEB> gvth: there's a filter for that but I'm pretty sure it's geared for non-live :) [13:50:18 CEST] <upgreydd> JEEB: I'm not sure what's that, searching how to activate it :D [13:50:30 CEST] <JEEB> I think the API option is aud=1 or something [13:51:06 CEST] <JEEB> yup [13:51:14 CEST] <JEEB> -x264-params "aud=1" or so [13:51:22 CEST] <JEEB> that should have it start writing AUDs [13:51:48 CEST] <JEEB> note: check the spec if that stuff you find is AUDs [13:51:54 CEST] <JEEB> I have no idea how AUDs look like :P [13:52:03 CEST] <durandal_1707> gvth: afade filter, you need to set start of fade manually, and not from end of stream [13:52:20 CEST] <JEEB> yea [13:52:38 CEST] <JEEB> durandal_1707: so I think that wouldn't work nicely with a live stream which is what I think gvth is doing? [13:53:03 CEST] <gvth> JEEB, durandal_1707: Could you please provide an actual sample command or a weblink? [13:53:37 CEST] <gvth> JEEB, durandal_1707: Using a search engine, I cannot find my issue being addressed [13:54:00 CEST] <durandal_1707> gvth: search ffmpeg afade filter [13:57:10 CEST] <upgreydd> JEEB: aud=1 is correct :D [13:57:11 CEST] <durandal_1707> also look at: https://github.com/guillaumekh/ffmpeg-afade-cheatsheet [13:58:25 CEST] <JEEB> upgreydd: ok, so it was AUDs? [13:58:58 CEST] <durandal_1707> gvth: http://ffmpeg.org/ffmpeg-filters.html#afade-1 [14:00:27 CEST] <durandal_1707> gvth: i could implement commands for afade, so you could do more advanced stuff [14:00:28 CEST] <gvth> durandal_1707: thanks, your last link addressed my issue [14:01:24 CEST] <upgreydd> JEEB: it's still not playing but it can be related to wrong header now xD [20:02:23 CEST] <Cracki> so... why does this page not link to actual documentation of libavcodec, only this kind of "book cover"? https://www.ffmpeg.org/libavcodec.html [20:02:51 CEST] <Cracki> I'm trying to get into libav* but mere lists of classes and function signature aren't gonna cut it [20:06:57 CEST] <Cracki> tbh these pages are pointless. _now_ I discovered I want "api" docs. that needs to be linked right there, or those pages can go. I really see no point in them existing. [20:11:10 CEST] <Cracki> also, where would I go to learn "big concepts" such as how AVCodec and AVCodecContext relate to each other, or how time bases between codec context, stream, container, ... relate, or how offsets between streams are treated, or how long (duration) the last frame of a video stream is presented [20:12:01 CEST] <JEEB> the last frame part is a really container specific thing. in some containers you have a duration, in many you don't [20:12:17 CEST] <JEEB> and yea, for the API docs site:ffmpeg.org doxygen trunk KEYWORD [20:12:23 CEST] <JEEB> is probably going to be the best way [20:12:27 CEST] <Cracki> I'm ok with answers, I'd be happy with knowing WHERE these things are written down [20:12:49 CEST] <Cracki> I'm looking for a written guide, not for a API reference [20:14:09 CEST] <Cracki> something that explains the rules of the game, not an engineering drawing of the chess pieces with metric dimensions [20:14:13 CEST] <JEEB> i don't think there's a step-by-step guide, you can take a look at the examples under doc/examples in the source tree. although beware of the "decoding" only or "encoding" only examples since they seem to take weird short-cuts like reading the file without lavf or outputting the encoded buffers etc [20:14:34 CEST] <JEEB> the transcoding example or transcode_aac examples are probably some of the better ones [20:14:53 CEST] <Cracki> I'm interested in encoding. too much stuff out there only treats decoding. [20:15:03 CEST] <JEEB> transcoding is the whole chain [20:15:28 CEST] <JEEB> and f.ex. the encoding-only stuff often leaves stuff out to "simplify" the example which I'm not sure is always of the best interest of the example [20:15:31 CEST] <Cracki> tbh, I treat these examples as "someone wrote this a while ago, NO GUARANTEE that it's what you're supposed to do" [20:15:41 CEST] <JEEB> if we provide helpers that make some things simpler [20:15:56 CEST] <Cracki> helpers are great, if they're explained [20:16:15 CEST] <JEEB> anyways, the transcoding example IIRC doesn't utilize the new dec/enc APIs yet. the transcoding_aac one I think is up-to-date on that [20:16:18 CEST] <Cracki> oh well, guess this is one of those days where I have to suppress my genocidal urges [20:17:04 CEST] <Cracki> what is the "dec/enc" api, is that documented already, what am I supposed to use [20:17:18 CEST] <Cracki> how am I supposed to decide what to choose [20:17:31 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [20:17:37 CEST] <JEEB> yes, it even has a general how-to guide :P [20:17:40 CEST] <Cracki> do the examples indicate which ones are "up to date" and which ones I should avoid? [20:17:57 CEST] <Cracki> how would I have discovered these facts on my own? [20:18:13 CEST] <Cracki> >Set up and open the AVCodecContext as usual. [20:18:19 CEST] <Cracki> so this assumes I know things already [20:19:00 CEST] <Cracki> the very first paragraph I expect to read on this "old/new" stuff is who and WHY this was deemed necessary [20:19:25 CEST] <Cracki> the second paragraph should explain the differences without assuming that the reader knows either the old or the new way already [20:19:52 CEST] <JEEB> jesus fuck [20:19:55 CEST] <Cracki> same [20:20:13 CEST] <Cracki> ffmpeg is in the position that there's no alternative [20:20:26 CEST] <JEEB> the APIs are not that fucking bad. [20:20:32 CEST] <Cracki> that's not what I said [20:20:35 CEST] <JEEB> it might not have perfect documentation, but vittu perkele [20:20:51 CEST] <JEEB> and I am not being paid to sit her and listen you ramble how you hate it [20:20:59 CEST] <Cracki> I said I need certain documentation, which I haven't found yet [20:21:41 CEST] <Cracki> such as, where is the general idea of time bases explained, and how it touches various classes in these libraries [20:21:41 CEST] <JEEB> anyways, the general thing is: lavf context for input reading and you get AVPackets, lavc context for each stream you want to decode and at this point you start getting AVFrames from decoder, then you do filtering in lavfi if you need to, then you open an encoder for stream(s) you need and finally you have an output AVFormatContext to which you stick the AVPackets received from the encoder [20:21:53 CEST] <JEEB> see the transcoding example for example [20:22:04 CEST] <JEEB> I am a shitty coder yet I could make a simple pice of shit with the API [20:22:15 CEST] <Cracki> you're familiar with it [20:22:20 CEST] <durandal11707> Cracki: please contact phone support [20:22:30 CEST] <JEEB> I fucking wasn't [20:22:37 CEST] <JEEB> i might have poked the internals [20:22:42 CEST] <JEEB> but not the external APIs [20:22:46 CEST] <JEEB> vittusaatana [20:22:50 CEST] <Cracki> I am sorry for this interaction. [20:22:57 CEST] <Cracki> and what does that word even mean [20:23:11 CEST] <JEEB> anyways, see the transcoding example for example [20:23:15 CEST] <JEEB> it will open an input avformat context [20:23:26 CEST] <JEEB> then use the fabulously misnamed av_read_frame [20:23:31 CEST] <JEEB> which gives you AVPackets [20:23:48 CEST] <JEEB> each packet will have an AVStream index marked on it [20:24:04 CEST] <JEEB> you can use the avformatcontext's list of AVStreams to figure out what stream that is [20:24:29 CEST] <JEEB> then you can create an AVCodecContext from the parameters of that input stream for decoding [20:24:48 CEST] <JEEB> then you use the feed/receive API as mentioned to get AVFrames out of AVPackets [20:25:17 CEST] <Cracki> this project has a codec of conduct... [20:25:32 CEST] <JEEB> then there's filtering if you need to change some parameters [20:25:47 CEST] <JEEB> then you search for an encoder you want f.ex. by its name [20:25:50 CEST] <Cracki> durandal11707, I'm sure you were joking because that's not at all what I was asking for [20:27:35 CEST] <Cracki> thank you JEEB, but you really don't need to. I understand now that there's no guide for this. [20:27:36 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encoding.html [20:27:55 CEST] <JEEB> there's avcodec_find_encoder_by_name f.ex. [20:28:12 CEST] <durandal11707> Cracki: than what you need? "FFmpeg API guide for dummies" book? [20:28:27 CEST] <Cracki> durandal11707, why so deprecating? [20:28:44 CEST] <JEEB> we havne't done major API changes in a few years now so please drop that meme [20:28:50 CEST] <Cracki> yes, maybe that's what I'm looking for, something that explains the concepts, not the apis [20:28:58 CEST] <JEEB> even the "new" encoding/decoding APIs are now two+ years old [20:29:04 CEST] <pink_mist> Cracki: probably because you come in here asking to be spoonfed without showing that you've actually done any work to figure things out on your own [20:29:22 CEST] <JEEB> Cracki: anyways please take a look at f.ex. the transcoding examples and ask here [20:29:36 CEST] <Cracki> pink_mist, why the hate [20:29:48 CEST] <Cracki> am I touching a sore spot somehow? [20:29:49 CEST] <pink_mist> and you claim that I'm hating you now ..? [20:30:05 CEST] <pink_mist> I was explaining that your attitude was pretty shitty [20:30:16 CEST] <pink_mist> if you want to make that into me hating you, you're mistaken [20:30:18 CEST] <JEEB> we are used to people asking "I tried x, y, z but I'm not sure if this is good" and pasting code [20:30:29 CEST] <JEEB> and then we have a discussion [20:30:35 CEST] <Cracki> I was explaining that I see an opportunity to improve the documentation [20:30:45 CEST] <Cracki> and you people come at me with aggression and insults [20:30:58 CEST] <Cracki> I'm not here to cause trouble, believe me [20:31:01 CEST] <pink_mist> Cracki: if you're willing to put in the work to improve the documentation it will be appreciated, I'm sure [20:31:04 CEST] <JEEB> ok. then there was some misreading of things if that is what you meant [20:31:14 CEST] <JEEB> because it really seemed like you were just herping a derp [20:31:23 CEST] <Cracki> I see that this project has a code of conduct, yet I get this kind of response from several people [20:31:41 CEST] <Cracki> I am very sorry that you have bad experiences. don't take it out on me. [20:32:01 CEST] <JEEB> but really, please take a look at the basic transcoding examples and/or explain your use case [20:32:05 CEST] <Cracki> I am also very sorry that I have to be the one to try to stay cool [20:32:12 CEST] <Cracki> I AM looking at that example [20:32:34 CEST] <JEEB> because by knowing your use case it'd be simpler to grab which parts you need [20:32:37 CEST] <pink_mist> what "this kind of response"? I'm being perfectly civil to you, yet you keep complaining that I must hate you? please stop doing that. [20:34:48 CEST] <Cracki> my concrete use case? write a video, qtrle codec, where the picture changes at specific times. [20:34:53 CEST] <Cracki> I have got that working. [20:35:17 CEST] <Cracki> but I have no idea if I set the right values in the right objects [20:35:33 CEST] <durandal11707> the explanation what time_base is not in documentation IIRC [20:35:53 CEST] <JEEB> ok, so no decoding etc? just getting raw video frames and feeding to an AVCodecContext you have created and then feeding that to the muxer? [20:35:54 CEST] <Cracki> on top of that, it's in python, with "pyav", the documentation of which consistently refers to libav* to know the details because it's a more or less thin wrapper [20:36:37 CEST] <JEEB> the problem with FFmpeg's APIs is that you can do so many things with it :P it's either you make a thin wrapper or you really limit yourself to a specific use case [20:36:42 CEST] <JEEB> both are valid approaches [20:37:09 CEST] <Cracki> I don't know what its "av.open" does but I have a qtrle stream, on which I set a time_base (probably wrong), and I have a codec_context for that stream, on which I can set gop_size=1 (for intra), and I have avframes on which i can set time_base and pts [20:37:37 CEST] <JEEB> Cracki: so you have your AVFrame with the raw video. it has a PTS on some time base. AVFrames by themselves (unfortunately) don't have time bases [20:38:08 CEST] <Cracki> but from setting and reading these fields, I noticed that it computes least common multiples (or gcd), so that's ok, but I'd like to know what I do that's right and what's just coincidentally not causing it to fail [20:38:10 CEST] <JEEB> so when you are taking some data into the FFmpeg's APIs for encoding, you just need to keep a view on what the time base is for your AVFrames [20:38:37 CEST] <JEEB> then when you create your AVCodecContext you set a time base to it [20:38:42 CEST] <Cracki> good, avframes don't have timebases, that's valuable info [20:39:04 CEST] <JEEB> before you feed the AVFrame to the encoder, you have to make sure that it is in the time base of the AVCodecContext [20:39:11 CEST] <Cracki> so on what object do I set the timebase? codec context? stream? container? [20:39:19 CEST] <Cracki> I realize containers might have time bases too [20:39:34 CEST] <JEEB> yes, on avformat level every *AVStream* has a time base [20:39:43 CEST] <JEEB> for example audio might have it 1/48000 [20:39:49 CEST] <Cracki> "in the timebase" meaning? that avcodeccontext has a timebase, and the frame's pts is in the context's time base? [20:39:50 CEST] <JEEB> and video might have 1001/24000 [20:40:26 CEST] <JEEB> Cracki: yes, when you feed an AVFrame to an encoder you use one of the built-in functions to move the value from whatever the previous time base was to the encoder's [20:40:56 CEST] <Cracki> does the stream take the timebase of its codeccontext, or do both objects need that set explicitly? [20:40:59 CEST] <JEEB> in your case you have raw data you're feeding from some input so just make sure your input AVFrames have pts on the time base set into your encoder AVCodecContext [20:41:10 CEST] <JEEB> avformat time bases are 100% unrelated [20:41:36 CEST] <JEEB> also avformat depending on the output container can change the time base to something that isn't what you asked for during init [20:41:39 CEST] <JEEB> for example [20:41:44 CEST] <JEEB> you might want to output FLV or MPEG-TS [20:41:49 CEST] <JEEB> both of these have hard-coded time bases [20:42:02 CEST] <JEEB> so even if you set a time base there, it will get set to 1/1000 or 1/90000 respectively [20:42:16 CEST] <JEEB> thankfully, that value is availbale in both structures after initialization to read [20:42:21 CEST] <JEEB> so you don't have to special case it [20:43:03 CEST] <Cracki> so... I use the context's timebase, and leave the stream's timebase alone? [20:43:08 CEST] <JEEB> when you init streams in an avformatcontext for muxing, you set a time base, and then when you are making sure that the pts/dts of the AVPacket are on the AVStream's time base, you just don't expect it to be something but instead read it from the output AVStream [20:43:20 CEST] <JEEB> no, the time base will be in the stream [20:43:32 CEST] <JEEB> after init it will get set to the hard-coded value or otherwise to the one you defined [20:43:41 CEST] <JEEB> so the logic is the same in both cases [20:44:00 CEST] <Cracki> I think I want to define a 1/1000 timebase because my desired presentation timestamps are at best millisecond precise [20:44:23 CEST] <JEEB> sure, and then if the container is somehow limited it will get set to something else if needed [20:44:35 CEST] <Cracki> I'm ok with a finer timebase, I just need to know what it'll be so I can compute pts right [20:44:51 CEST] <JEEB> yes, it is in the AVStream and there's even a function for the rescaling [20:45:04 CEST] <JEEB> I don't remember what it was - it takes an AVPacket [20:45:19 CEST] <Cracki> I have seen these translation functions. I'll have to check how this python wrapper library does it [20:45:21 CEST] <JEEB> and you give it the encoder context's time base and the AVStream's time base as params [20:45:34 CEST] <JEEB> so basically you have your input data on some time base [20:45:45 CEST] <JEEB> then you initialize the encoder lavc context with some time base [20:46:00 CEST] <Cracki> so, just asking if I understood it... it translates a frame's pts, from context timebase, to stream timebase? [20:46:01 CEST] <JEEB> at that point you rescale the pts of the AVFrame to the lavc context's time base [20:46:16 CEST] <JEEB> Cracki: in case of the AVPacket function it scales all time related things [20:46:20 CEST] <JEEB> pts, dts, duration [20:46:24 CEST] <Cracki> good [20:46:38 CEST] <JEEB> basically when encoding you set two time bases [20:46:45 CEST] <JEEB> the encoder and the streams' [20:47:01 CEST] <JEEB> (well there can be more than two of them if you encode multiple streams but you get the idea hopefully) [20:47:11 CEST] <JEEB> but two places for each stream you encode & mux :P [20:47:30 CEST] <Cracki> encoder/stream (almost) always come in pairs? [20:47:38 CEST] <Cracki> uh codec context [20:47:51 CEST] <JEEB> well if your idea is to encode something and then mux it, you will have those two [20:47:56 CEST] <Cracki> ic [20:48:15 CEST] <JEEB> then if you need filtering the filter chain input and output has time bases as well, but in your case it sounds like you're not filtering [20:48:23 CEST] <Cracki> aye [20:48:34 CEST] <JEEB> so you have some data, and some timestamp for that data [20:48:52 CEST] <JEEB> what you make sure is you feed the lavc encoder context the AVFrames with values on the time base that you set the encoder to [20:49:13 CEST] <Cracki> encoder = avcodeccontext? [20:49:20 CEST] <JEEB> yes, that's why I keep noting lavc [20:49:23 CEST] <Cracki> k [20:49:30 CEST] <JEEB> l(ib)avc(odec) [20:49:35 CEST] <JEEB> as opposed to lavf for libavformat [20:49:42 CEST] <JEEB> or lavfi for filtering [20:49:46 CEST] <JEEB> (libavfilter) [20:50:05 CEST] <JEEB> and then after you receive AVPackets from the encoder lavc context, you just rescale the AVPackets' values to the output stream's time base [20:50:11 CEST] <JEEB> and you should be golden [20:50:26 CEST] <Cracki> aha! I rescale the packets' time fields [20:50:35 CEST] <JEEB> yes, there's a function for that [20:50:47 CEST] <Cracki> thanks for this explanation. [20:50:54 CEST] <JEEB> so you rescale from the lavc context time base to the lavf context's AVStream's time base [20:51:15 CEST] <Cracki> wasn't sure (on) what the function precisely rescales [20:51:31 CEST] <JEEB> I think it's pts,dts,duration [20:51:37 CEST] <JEEB> since those relate to time [20:52:43 CEST] <JEEB> basically the AVPacket taking rescale function is supposed to handle all time related values for you between time bases so you don't have to care [20:52:51 CEST] <JEEB> anyways, I need to finish cooking :P [20:53:00 CEST] <JEEB> it kind of got paused when I started chatting here [20:53:31 CEST] <durandal11707> JEEB forgets real life events while chatting on IRC [20:53:33 CEST] <Cracki> k lemme put it in my own words. I create a codec context with a time base. avframes get pts and such in that timebase. I create a stream for that codec context. the stream might get a different timebase. the codec context encodes an avframe into packets, and the packets initially have codec context timebase. I need to translate these times into *stream* timebase using that helper function. [20:53:49 CEST] <Cracki> bon appetit [20:54:29 CEST] <JEEB> yup [20:54:33 CEST] <JEEB> also this was the function https://svn.ffmpeg.org/doxygen/trunk/group__lavc__packet.html#gae5c86e4d93f… [20:54:38 CEST] <durandal11707> aren't you using ffmpeg api via python? how that even works? [20:54:38 CEST] <JEEB> av_packet_rescale_ts [20:55:26 CEST] <JEEB> Cracki: basically if you were filtering or decoding before your AVFrames would be in the time base of either the filter chain output or the decoder lavc context. in your case your input is generated by you [20:55:40 CEST] <Cracki> appears to be an OOP wrapper around it. libav* are classes already so it's not that much of a stretch. https://github.com/mikeboers/PyAV [20:55:42 CEST] <JEEB> so you should know exactly the times of your input AVFrames when you generate them [20:56:09 CEST] <Cracki> that is correct [20:56:19 CEST] <JEEB> your line just sounded like newly created AVFrames by default would be in the lavc context's time base. they will not be. [20:56:32 CEST] <JEEB> since AVFrames by themselves just lack any time base and the timestamps are by default NOPTS [20:56:35 CEST] <JEEB> or so [20:56:51 CEST] <JEEB> so you just make sure your your timestamps are on the correct time base you set for the lavc encoder context [20:57:04 CEST] <JEEB> before feeding that created data into the encoder [20:57:09 CEST] <JEEB> I hope that's clear enough [20:57:51 CEST] <Cracki> ah! so I could just create avframes with no time information at all, pass that through the codec context, and set pts and such (in stream timebase) on the resulting packets? [20:57:57 CEST] <JEEB> no [20:57:59 CEST] <JEEB> please don't do that [20:58:02 CEST] <Cracki> heh good [20:58:07 CEST] <JEEB> ok, so my explanation was shit [20:58:36 CEST] <Cracki> I understand avframes have no timebase, so their time values are interpreted depending on what uses them [20:58:42 CEST] <JEEB> yes [20:59:08 CEST] <JEEB> and you are generating the input so you just make sure that your PTS of AVFrames is the same as the lavc encoder context's [20:59:15 CEST] <Cracki> so what comes out of a codec context is AVPackets, which do have a timebase, and it'll be the timebase of the codec context [20:59:28 CEST] <JEEB> no, the AVPackets don't have a time base either [20:59:34 CEST] <Cracki> ah good [20:59:39 CEST] <Cracki> it's starting to make sense [20:59:49 CEST] <durandal11707> water is boiling, kitchen is overheating already [20:59:51 CEST] <JEEB> basically their timestamp etc values depend on what created them [21:00:08 CEST] <JEEB> so since you set time base on the encoder, the created AVPackets will be on that time base [21:00:10 CEST] <Cracki> can I assume that the packets for a frame get the same PTS, but DTS will be determined by codec/context? [21:00:55 CEST] <JEEB> for audio you have encoder delay so the packets can start with a negative timestamp [21:01:14 CEST] <JEEB> so you have like 1024 or whatever samples of encoder initialization stuff first [21:01:27 CEST] <JEEB> which does decode into stuff, but should be marked as pre-ezro [21:01:29 CEST] <JEEB> *zero [21:01:35 CEST] <JEEB> so the PTS is not always the exactly same thing [21:01:38 CEST] <Cracki> and not played back? interesting [21:01:54 CEST] <JEEB> it is often played back, which is where the negative timestamps also come in handy [21:01:58 CEST] <Cracki> ic [21:01:59 CEST] <JEEB> because it keeps the A/V sync [21:02:11 CEST] <JEEB> since the zero point is the start of the actual encoded audio as opposed to encoder delay [21:08:47 CEST] <Cracki> some automagic picks up on my first frame not having pts 0, and using the first frame's pts as the stream's "start", so even though I might want the first frame to be presented at 17 seconds... how does that happen, and is it even *possible* to have the video black/blank at the beginning and seeing the first frame only after a while [21:09:54 CEST] <Cracki> avstream::start_time appears to determine this. I'll try that. [21:10:27 CEST] <Cracki> oh, docs warn me against setting anything else there [21:12:35 CEST] <Cracki> it's probably best to create an explicit first frame... [21:54:55 CEST] <A4L> why are movies usually stored in avi formats when mp4 is more storage efficient (movies on TPB etc...)? [21:57:15 CEST] <der_richter> avi and mp4 are containers and those don't directly relate to storage efficiency/quality etc [21:57:35 CEST] <der_richter> it's rather the formats/codecs used for the streams packed into those containers [21:59:40 CEST] <A4L> so if I just `ffmpeg input.avi output.mp4` it should not make any filesize difference and I should instead look into H.264 codec settings if I want to make compression inprovements? [22:00:01 CEST] <furq> you should probably just be better at piracy [22:00:04 CEST] <furq> nobody uses avi any more [22:00:24 CEST] <der_richter> there might be a small diffrence, which is negligible [22:00:32 CEST] <Ariyasu> lol [22:00:52 CEST] <Ariyasu> ren *.avi *.mp4 [22:01:03 CEST] <der_richter> if it's about video, yeah look into a better codec, codec settings or encoder [22:01:52 CEST] <Cracki> and use -c copy to be sure it's copying the streams, not transcoding them [22:02:24 CEST] <A4L> yeah, thanks, you are right, I got smaller filesize just because CRF was 23 by default... :facepalm: yeah, I have read H.264 docs and I think I get it now. see ya [22:03:06 CEST] <A4L> Cracki: if I use -c copy I cant modify crf, preset and tune options, right? [22:03:16 CEST] <Cracki> that's the point, it copies the streams [22:04:37 CEST] <A4L> yeah, but I am trying to compress the video, so I will use -crf 23 and -preset slow and -acodec copy (only audio) and not -c copy (a&v), right? [22:04:47 CEST] <Cracki> right [22:04:55 CEST] <A4L> k tnx [22:05:50 CEST] <Ariyasu> -vcodec libx264 [22:05:55 CEST] <Ariyasu> don't forget that bit [22:06:11 CEST] <Ariyasu> you might want to use a higher crf value also [22:06:27 CEST] <Ariyasu> like 21ish i guess it depends on type of content [22:06:44 CEST] <Ariyasu> if it's scripted you might want to use like 17 or 18 [22:11:29 CEST] <A4L> ok [22:14:33 CEST] <A4L> yeah, i will use 18, it should be "visually lossless"... [22:15:56 CEST] <upgreydd> JEEB: still fighting xD Still online? [22:28:47 CEST] <A4L> conclusion: after running it for 5 movies at veryslow, 18, film, libx264, I figured out that my films are already very optimised and compressed and further compression would be useless. so yeah, TPB-ish movies are already at best quality/filesize... [22:31:24 CEST] <Ariyasu> no [22:31:44 CEST] <Ariyasu> the best quality == bd/dvd source mpeg2 [22:31:57 CEST] <Ariyasu> best filesize = debatable [22:32:28 CEST] <upgreydd> OK, looking for option to get x264-params from existing file cause I need encode second one very simillar. Is there some analyzer available? For example all headers was looking same in both files but one was with option "aud=1" and it was noticable only in hex :/ any advices please? [22:35:21 CEST] <frubsen> hey, anyone here know much about ffmpeg and decklink? [23:57:05 CEST] <aldenp> hi, so I'm getting a bunch of ALSA `underrun occured` errors when playing back with ffplay [00:00:00 CEST] --- Mon May 27 2019

1 0