00:03 <cone-757> ffmpeg Peter Ross master:ae8295417adf: avformat/rmdec: support RMHD file format

00:03 <cone-757> ffmpeg Peter Ross master:33802e7c3237: avcodec/rv60: RealVideo 6.0 decoder

00:03 <cone-757> ffmpeg Peter Ross master:2d81eaa37bba: fate/rv60: add test

00:10 <thardin> pal: probably not

00:12 <pal> ok, so we should plan on merging midweek unless we hear otherwise...

00:17 <thardin> mayhaps

00:18 <thardin> at the pub atm

00:49 <pal> enjoy... same for me soon.

07:36 <JEEB> huh, this mentions RPI and seems to be a P010 patch for v4l2? https://github.com/awawa-dev/P010_for_V4L2 . whatever this HyperHDR thing is

07:38 <JEEB> oooh, it's for capture devices, so actual original v4l2 use case (https://github.com/raspberrypi/linux/pull/6451)

07:39 <JEEB> and here I hoped someone had poked the decoding hardware to force it output P010 :P

08:13 <fflogger> [editedticket] nyanmisaka: Ticket #11280 ([undetermined] Strange green flickering line added with a hevc_vaapi reencode) updated https://trac.ffmpeg.org/ticket/11280

13:59 <martin__--> Hi, when executing make I run into the following issue: CC=/c/opt/gcc-7.1/bin/gcc CXX=/c/opt/gcc-7.1/bin/g++ ../ffmpeg-2.8.22/configure --enable-nonfree --disable-doc --disable-manpages --enable-shared --extra-libs="-lpthread -lm" --enable-gpl

14:00 <martin__--> make doc/Makefile:182: no file name for `-include' `doc/Makefile:182: no file name for -include` `Makefile:127: no file name for -include` `tests/api/Makefile:9: no file name for -include` `tests/Makefile:232: no file name for -include` `make: *** No rule to make target libavdevice/libavdevice.so, needed by ffmpeg_g. Stop.` `debian-sparc:~/ffmpeg-2.8.22# cd ..`

14:01 <jamrial> this channel is for development. usage questions go to #ffmpeg

15:43 <llyyr> elenril: vf_libplacebo causes a segfault since 8160178dfc0e6bdaacf80dec58e595a9d595eedc

15:43 <llyyr> reproducible with ffmpeg -i in -init_hw_device vulkan -vf libplacebo out

15:44 <llyyr> cc haasn ^

16:23 <Daemon404> blimey

16:57 <elenril> > This is how ffmpeg came to support ProRes and DNxHD, Apple and Avid paid for the support to be added.

16:57 <elenril> llyyr: can you get a backtrace?

16:59 <llyyr> elenril: https://0x0.st/XGvT.txt

17:04 <elenril> weird

17:06 <elenril> I'll try to have a closer look tomorrow

17:09 <thardin> reading up on the VP8/9 MIME spec. VP8 has levels?

17:09 <thardin> ffprobe says level=-99 for a VP8 file encoded with libvpx

17:09 <llyyr> FWIW simply reverting that commit on top of master also fixes the issue

17:10 <elenril> that would be Wrong though

17:16 <thardin> pal: as long as it isn't wildly different it's probably fine

17:33 <thardin> seems like type="video/webm; codecs=&quot;vp9, opus&quot;" is also an acceptable way to specify codecs, not just that cumbersome four-part MIME thing for vp8/9

17:33 <thardin> and similarly with vp8+vorbis

17:39 <thardin> why do so few codecs use general purpose compressors? I remember fiddling with lossless compression and just tossing a transformed file at gzip and/or bzip2 easily beat flac

18:38 <johnny__> I might end up in the hospital after 1.5 days of trying to figure this out in the code: What the heck does -maxrate do in ffmpeg? Nobody seems to know. I say that because everyone gives conflicting answers. Take this example: -b:v 3M -maxrate 6M -bufsize 12M. This tells ffmpeg to monitor libx264 to aim for 3Mbit (b:v). But after this, everyone's explanations fall apart. The -bufsize is the size of the variable bitrate buffer. But

18:38 <johnny__> after that, nobody seems to know.

18:39 <johnny__> Here's what I think: FFmpeg will attempt to hit the b:v bitrate. It will collect data in the -bufsize. When -bufsize is full, it will divide the size by the length of time inside the buffer to find out what the average bitrate was for that time period, and will adjust it up/down to aim at the b:v target.

18:40 <cone-566> ffmpeg Michael Niedermayer master:ebffb8b68efc: avcodec/ffv1enc: Tighter maxsize

18:40 <cone-566> ffmpeg Michael Niedermayer master:df00705e0010: INSTALL: explain the circular dependency issue and solution

18:40 <johnny__> How does -maxrate act? Does it constantly monitor the current bitrate and instantaneously detect spikes before the -bufsize has completely filled? Or does it only enforce -maxrate when -bufsize is full?

18:41 <johnny__> And lastly, doesn't -maxrate 6M mean that the stream could permanently sit at 6 Mbit instead of -b:v's 3 Mbit?

18:41 <llyyr> depends on the codec used, also this isn't the user help channel

18:41 <llyyr> s/codec/encoder

18:42 <johnny__> Well I'm a developer, working on an open source streaming tool that will use FFmpeg. And I don't trust the users answers since everyone has conflicting answers about this. Literally 1.5 days of research so far.

18:42 <johnny__> The encoder is libx264.

18:43 <johnny__> The core questions that everyone has different answers to are: Is -maxrate instantaneously enforced or only when -bufsize is full (when each chunk checks the average bitrate). And how does -maxrate interact with -b:v to ensure that we don't sit at -maxrate permanently?

18:47 <llyyr> -maxrate is the upper limit on the bitrate for the bufsize you set, according to the docs

18:49 <johnny__> Thanks for checking. Yeah I've read those docs, and the wiki pages about streaming, and about 50 stackoverflow questions, and tried to figure it out in the source hehe. Nowhere does it say how it's enforced. All I know for sure is that -maxrate requires -bufsize to also be set, so they are intimately linked.

18:49 <jkqxz> Maxrate defines how fast the data is added to the HRD (VBV) buffer.

18:50 <jkqxz> It's the fixed channel bitrate which must be maintained to avoid any skipping if you follow the HRD buffering model.

18:51 <jkqxz> The encoder understands the model and ensures that the result follows the constraints of the model.

18:53 <johnny__> Hmm sounds interesting, this is the first time I hear that explanation. Here's the best references but none were clear: https://ffmpeg.org/ffmpeg-codecs.html https://trac.ffmpeg.org/wiki/EncodingForStreamingSites https://trac.ffmpeg.org/wiki/Limiting%20the%20output%20bitrate

18:54 <johnny__> They all say that -maxrate is the maximum output rate (bandwidth/bitrate). And that it requires -bufsize to be set too (recommended value: 2x maxrate). But none say how it's enforced.

18:54 <johnny__> Oh and the point is that `-b:v` sets the target, but that `-maxrate` allows the average target rate to be exceeded during scenes that are extra complex.

18:55 <johnny__> But where it falls apart for me is how is -maxrate enforced? It's clearly intimately linked to having a -bufsize (it won't work without it, according to docs).

18:55 <jkqxz> "how it's enforced" is not really a meaningful question. The encoder ensures that the stream stays within the bounds of the HRD buffer.

18:55 <jkqxz> (Doesn't overflow or underflow.)

18:56 <johnny__> 1. Is it enforced frame by frame, or when bufsize is full? The normal -b:v is only enforced/changed when bufsize is full. It uses each bufsize chunk to see what the target compression amount needs to be adjusted towards. 2. What prevents -maxrate from always pegging at maxrate? Is it going to be driving towards -b:v at all times and -maxrate is just headroom during complex scenes?

18:57 <johnny__> I saw warnings that if -b:v and -maxrate is the same value, the encoder can freak out and push the brakes on complex scenes that rapidly fill the -bufsize, leading to blockiness. So I was thinking that our default formula for users should be: -b:v user target, -maxrate: 1.2 x b:v, -bufsize: 2x maxrate.

18:58 <jkqxz> 1. The bounds only say that the HRD buffer doesn't overflow or underflow; a good encoder adjusts things earlier when it thinks it might be in danger (ideally with lookahead to see future stream complexity).

18:59 <jkqxz> 2. The encoder wants to hit the average rate over the whole stream within the HRD buffer constraint, pegging at maxrate is not that.

18:59 <johnny__> Thanks a lot, that really nails the explanation. The "a good encoder adjusts earlier" fits with a few of the conflicting answers I'd read. Thanks a lot. That clarifies that libx264 is susceptible to the "maxrate == b:v" sudden panics when complex scenes arrives, so we'll set maxrate to 20% more than b:v by default.

19:00 <johnny__> Thank you so much. You put an end to probably 20 hours of trying to figure this out. <3

19:00 <johnny__> I didn't want to bother you but every answer I found was different. :)

19:01 <jkqxz> Bitrate and maxrate the same means you have hard CBR, which is bound to do badly when the stream complexity changes (though with a large enough buffer size may be ok).

19:01 <jkqxz> I do suggest reading the HRD specification (H.264 annex C) if you want to understand how the maxrate constraint works (and therefore how it is intended to apply to streaming cases).

19:02 <johnny__> Yeah that's the warning I kept finding, so we'll avoid hard-CBR for the defaults. "maxrate=1.2x b:v" is not a lot extra but seems like a conservative way to help with those hard brakes.

19:02 <johnny__> Thanks for the spec information! <3

19:07 <johnny__> Oh and one minor thing... bufsize, we'll default to 2x maxrate since I kept seeing that on the ffmpeg wiki links above, regarding livestreaming. From what I understood, the general -b:v bitrate is re-adjusted every time bufsize fills up, so it seems like longer values avoid sudden quality fluctuations, while short-ish values (bufsize=2x maxrate) are needed to ensure we stay near target. Is this a sane default?

19:07 <jkqxz> If you have a streaming use-case then ask the question in the other direction.

19:08 <jkqxz> What channel rate can you maintain and how much delay in the stream can you tolerate?

19:08 <johnny__> Yeah. Bufsize didn't seem to introduce delay though? It was just about bitrate history analysis and re-adjustments?

19:09 <johnny__> We just want to ensure that the defaults keep the bitrate roughly around -b:v with allowed spikes to -maxrate.

19:09 <jkqxz> For best encode you set maxrate to infinity for completely free VBR. Any constraint is trading quality for streaming-friendliness.

19:11 <johnny__> Yeah, that makes sense. Just trying to hit some sane default constraints. Looks like we'll default to "-b:v user target, -maxrate: 1.2 x b:v, -bufsize: 2x maxrate".

19:11 <jkqxz> Buffer size is setting the buffering delay (buffering delay == buffer size / maxrate).

19:12 <johnny__> Oh. Hehe. Saw a bunch of people saying it had no effect on latency and only controlled the size of the buffer that analyzes historical bitrates for re-adjustment. It's news to me that it actually controls an output buffer delay.

19:12 <johnny__> Heck even the wiki says `-bufsize specifies the decoder buffer size, which determines the variability of the output bitrate` at https://trac.ffmpeg.org/wiki/Limiting%20the%20output%20bitrate

19:13 <johnny__> Decoder buffer. Hmm. Wait, is that referring to the playback device's decoder? Then it would be a latency after all.

19:13 <jkqxz> Though also consider -rc_init_occupancy, which is the initial delay before you can start playing from the buffer (which can be less than the whole buffer if the encoder knows that it can fill it up later).

19:14 <jkqxz> Yes, all of these numbers are defined from the perspective of the buffering on the decoder.

19:15 <johnny__> Ahh. That explains a lot. Thanks for `-rc_init_occupancy` too. We have about 2 seconds time-to-picture at the moment and can probably get this down thanks to this advice. :) Smaller bufsize, maybe 1.5x maxrate. And smaller -g GOP. And will explore -rc_init_occupancy.

19:17 <johnny__> Last question, I swear, but it just hit me: We've been wondering if scene change detection in libx264 is good or bad while streaming? More I-frames = better quality and sooner picture. But more bitrate usage. Hmm.

19:17 <jkqxz> Do you have periodic intra pictures already?

19:18 <johnny__> Yeah, if you are referring to GOP, which is currently forced at -g 50 (have been afraid to lower it due to full frame bitrate usage)

19:18 <jkqxz> The point of scene change detection is to truncate a GOP on a picture which has no good reference (will be encoded to a size which is close to an intra picture anyway) in order to save having to insert an intra picture later.

19:19 <jkqxz> If you have a fixed GOP anyway (because of stream fragments or whatever) then it is actively harmful.

19:20 <johnny__> Ahh so encoding big scene changes without I-frames is roughly the size of an I-frame...

19:20 <johnny__> But with our fixed GOP I guess it means we'd waste space anyway since the fixed GOP interval would always be inserted anyway.

19:21 <johnny__> So we'll turn off scene change detection. Thanks a lot.

19:22 <johnny__> That's it. I appreciate it so much. Too many days trying to find answers on the wiki and stackoverflow and finding exactly opposite explanations from different people. I was on the brink of breaking down. :D

19:30 <johnny__> Oh I just realized what you meant: Scene change detection forcing truncation of the current GOP would mean that the streaming chunks become malformed/shorter than intended. *That's* how it's harmful. Makes sense now.

19:44 <jkqxz> Either that or you have an intra frame later at the fixed location anyway and the stream is larger than it otherwise could be, yes.

19:48 <johnny__> Ah. So that happens too. I thought a truncated GOP would just mean that the counter restarts, so it might go: GOP=50, GOP=33 (scene change), GOP=50, GOP=50, etc. But sounds like it always uses the fixed `-g` interval even when scene changes truncated the current GOP?

19:55 <jkqxz> Yeah, it can use either form depending on options.

19:55 <jkqxz> For encoding to a file where GOP size is setting the seek interval there is no penalty to an extra seek point and so you want the form you said, but fragment cases generally want the opposite so they are fixed length.

20:01 <johnny__> Makes sense. I also finally understood the -bufsize thanks to you and re-reading the two ffmpeg wikis. It's the memory allocation on the decoder and is also used by the encoder for analysis of what frames will be in the decoder's buffer, so a larger buffer allows the encoder to do various optimizations such as repeated frame detection. And longer values also allow more bitrate spikes during complex scenes (but never higher than `-

20:01 <johnny__> maxrate`). It's all coming together now.

20:05 <johnny__> And as you mentioned, a longer buffer increases decoder latency. Not sure how though, since I-frames can be displayed instantly and independently, and everything after that can be decoded in realtime. Unless you meant that bufsize leads to some extra latency in terms of milliseconds due to more complex encoding frame references/larger buffer. Hehe.

20:10 <johnny__> Mmm. I just tried a quick `-b:v 3500k -maxrate 3500k -bufsize 350000k` for fun and it didn't cause any noticeable decoder latency.

20:10 <johnny__> So that's good, I won't have to fear that bufsize will introduce seconds of delay.

20:13 <johnny__> From what I can see then, `-bufsize` just affects the encoder's interval for when it adjusts the target bitrate, the usage of some encoding optimizations, and the potential memory usage on the decoder side.

20:33 <fflogger> [editedticket] sramacher: Ticket #11258 ([undetermined] 7.1 regression: illegal instruction on riscv64) updated https://trac.ffmpeg.org/ticket/11258

20:35 <Sebastinas> jamrial, courmisch: Added more context to #11258. git bisect suggests that the regression was introduced in 324899b7483529c336f399022c63721df14663ef.

22:58 <johnny__> Hmm. There is debate (even in FFmpeg's own wiki) about whether `-bufsize` should be 2x `-maxrate` or `-b:v`. It makes more sense to me that it should be based on `-b:v` since that's the average rate we are aiming for. We aren't aiming for constant peaks. And "2x b:v" is also what Intel recommends.

22:59 <johnny__> I've read the HRD description so b:v is the only answer that makes sense to me, since the goal of the HRD buffer is to be exactly half-full, so `-b:v` seems like the correct reference.