[Ffmpeg-devel-irc] ffmpeg.log.20170821

[burek]

[04:59:21 CEST] <vans163> hello. is there a way to know what kind of YUV420 colorspace was used?
[04:59:43 CEST] <vans163> I see there is 3 predominant kinds, and on my decoder I am getting some blurry text, but decoding with VLC is fine
[04:59:51 CEST] <vans163> I am wondering if this can be the issue?
[06:22:10 CEST] <dan3wik> Anyone know of a low latency, low bandwidth video format or system that they could point me to?
[06:22:41 CEST] <dan3wik> It needs to be embeded in a website.
[06:23:10 CEST] <dan3wik> Right now we are using mpeg1video but I would prefer if we had something more up to date.
[06:25:51 CEST] <dan3wik> The hardware we are using can encode accelerated h264, but I heard that h264 needs full framesets before it can start to render them meaning it would add at least 2 seconds latency.
[06:34:46 CEST] <Wallboy> I have a video with a SAR of 4:3 and a DAR of 16:9. When playing it back in MPC it displays as 16:9. My video chain currently scales a video to a 16:9 aspect resolution while maintain the original aspect and adding black bars if needed like so: "[0:v]scale=640:360:force_original_aspect_ratio=decrease,setsar=sar=1/1,pad=640:360:(ow-iw)/2:(oh-ih)/2[out]"
[06:35:13 CEST] <Wallboy> However when the SAR and DAR differ like this, the encode "squishes" the video down to 4:3
[06:35:38 CEST] <Wallboy> i'm sure it's just a matter of putting setsar or setdar in the correct spot to fix the problem
[06:42:04 CEST] <kerio> dan3wik: h264 can be encoded with one frame of latency
[06:42:17 CEST] <kerio> by doing some Advanced Magic
[06:42:44 CEST] <dan3wik> The encoding isn't the issue, its the browser side I'm having issues with
[06:42:58 CEST] <dan3wik> There doesn't seem to be a low latency player available
[06:43:53 CEST] <kerio> yeah the best you can do is webrtc
[06:49:15 CEST] <dan3wik> kerio, what would the browser support be for something like that?
[06:49:26 CEST] <kerio> chrome and firefox
[06:49:42 CEST] <dan3wik> Ok, know of any it wont support?
[06:50:25 CEST] <dan3wik> And, what about moobile support?
[08:04:05 CEST] <robswain[m]> Webrtc with h264 will be supported in the next Safari release with iOS 11/macOS high sierra
[08:04:25 CEST] <robswain[m]> And webrtc is supported in chrome on android
[08:04:58 CEST] <robswain[m]> dan3wik: ^
[08:05:54 CEST] <dan3wik> ok
[08:06:15 CEST] <dan3wik> I'm looking into it right now, it seems relatively easy to implement.
[08:15:07 CEST] <Casper> Hi there, is there a way to rotate a video without reencoding? My guess is nope... but who knows...
[08:59:24 CEST] <Cracki> your guess is right, generally.
[08:59:48 CEST] <Cracki> some container formats (mov, mp4?) allow setting transform matrices, so you can rotate this way
[09:00:05 CEST] <Cracki> it's like rotating a jpeg image by setting metadata.
[09:00:23 CEST] <Casper> and supported by all players? or select few?
[09:00:37 CEST] <Cracki> some players disregard such information, as I'm sure you've seen when taking photos and looking at them
[09:01:41 CEST] <Casper> and I guess windows media player will ignore it...
[09:01:42 CEST] <Cracki> I have no idea whether this is mandatory behavior, and for which container formats, or if whatever video codec you used can take this information either
[09:01:49 CEST] <Cracki> don't guess.
[09:01:50 CEST] <Cracki> try.
[09:02:01 CEST] <Cracki> research this.
[09:02:14 CEST] <Casper> do you have some link about it?
[09:02:42 CEST] <Cracki> https://ffmpeg.org/pipermail/ffmpeg-devel/2009-November/076928.html
[09:02:46 CEST] <Cracki> this is something I just found
[09:03:16 CEST] <Cracki> I know of the existence of that metadata because I implemented some mov/mp4 parsing for my own purposes and saw it in the documentation of the mov format
[09:03:28 CEST] <Casper> ok  thanks   will look into it
[09:04:01 CEST] <Cracki> https://developer.apple.com/library/content/documentation/QuickTime/RM/MovieBasics/MTEditing/K-Chapter/11MatrixFunctions.html
[09:04:09 CEST] <Cracki> somewhere on that domain is the mov file spec
[09:04:17 CEST] <Cracki> mp4 is a subset of mov, afaik
[09:04:36 CEST] <Cracki> (probably not exactly)
[09:05:01 CEST] <Cracki> https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFPreface/qtffPreface.html
[09:05:27 CEST] <Casper> thanks   will check that tomorrow
[09:05:43 CEST] <Casper> now I should kick myself to do the dishes, then hit the bed...
[09:05:53 CEST] <Casper> don't want to, as every night
[09:06:24 CEST] <Cracki> always lick the dish you finish. less cleanup
[09:10:04 CEST] <Cracki> mvhd/tkhd contain a 3x3 matrix https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html
[10:32:05 CEST] <flux> when muxing h264 to mp4, how does ffmpeg find the codec configuration ("extradata")? when I try to do it (well, just really open h264), extradata ends up being null.
[12:59:20 CEST] <paveldimow> save
[13:05:51 CEST] <styler2go> Can i somehow transcode rtsp to mjpeg on the fly?
[13:32:49 CEST] <Fyr> guys, what is h264_mp4toannexb option for?
[13:33:59 CEST] <jkqxz> Changing H.264 from MP4 format to Annex B format.
[13:34:24 CEST] <Fyr> jkqxz, does FFMPEG do it by default when remuxing from MP4 to TS?
[13:35:19 CEST] <jkqxz> Yes.
[13:35:30 CEST] <Fyr> great
[13:35:39 CEST] <furq> it does now
[13:35:47 CEST] <furq> if you're on an old ffmpeg you'll need to specify the option
[14:12:53 CEST] <styler2go> Can i somehow convert a rtsp to html5 video?
[14:15:24 CEST] <BtbN> "html5 video"?
[14:15:27 CEST] <BtbN> So, an mp4 file?
[14:46:59 CEST] <styler2go> BtbN, yes
[16:22:03 CEST] <nivoh> hey guys (8
[16:22:59 CEST] <nivoh> im trying to understand how to use ffmpeg, is there any guide or something?
[16:23:35 CEST] <nivoh> need to re encode a flv file into an avi one
[16:30:43 CEST] <klaxa> nivoh: ffmpeg -i input.flv output.avi
[16:33:44 CEST] <nivoh> thanks
[16:33:51 CEST] <nivoh> but i dont get how to install it
[16:35:53 CEST] <Nacht> nivoh: What OS do you want to install it ?
[16:38:34 CEST] <nivoh> im in w8
[16:40:03 CEST] <Nacht> nivoh: You can download a build here: https://ffmpeg.zeranoe.com/builds/
[16:40:37 CEST] <Nacht> It's a ZIP file with the binaries in it. Just unpack it where you like, and you can run the executables from there.
[16:41:51 CEST] <Nacht> If you wish to be able to use ffmpeg from any path when you're using cmd, be sure to add the path where you unpacked the executables to your PATH in your environment variables
[16:42:45 CEST] <Nacht> Here's a simple website explaining it all: http://adaptivesamples.com/how-to-install-ffmpeg-on-windows/
[17:19:19 CEST] <nivoh> thanks dude (:
[18:55:24 CEST] <kerio> where can i find some docs related to ffvhuff/huffyuv?
[18:55:48 CEST] <kerio> a paper or something, maybe? something citable
[19:02:42 CEST] <pgorley> kerio: have you tried google scholar?
[19:03:07 CEST] <pgorley> not sure what you're looking for, but a few links turn up
[19:03:09 CEST] <JEEB> kerio: IIRC it was just huffman coding and some intra prediction
[19:04:28 CEST] <kerio> pgorley: lmao, this article cites ffvhuff as `FFMPEG [Online]. Available: http://www.ffmpeg.org`
[19:04:34 CEST] <kerio> thanks fam
[19:04:39 CEST] <kerio> 10/10 bibliography
[19:04:46 CEST] <JEEB> kerio: https://wiki.multimedia.cx/index.php/HuffYUV
[19:06:32 CEST] <JEEB> and I think ffvhuff is similar
[19:10:03 CEST] <dbogdanov> Hello. I want to build a shared library linking with a static libavcodec.a. I get an error: "libavcodec.a(deinterlace.o): relocation R_X86_64_PC32 against symbol `ff_pw_4' can not be used when making a shared object; recompile with -fPIC". However, I can't manage to build ffmpeg to fix this error. I've tried --enable-pic flag. Anybody can help?
[19:12:37 CEST] <JEEB> dbogdanov: have you made sure you cleared your build directory when adding enable-pic?
[19:16:13 CEST] <dbogdanov> Yes I did
[19:17:06 CEST] <dbogdanov> It appears to be an old problem: http://libav-users.943685.n4.nabble.com/Libav-user-compiling-ffmpeg-with-fPIC-td4657469.html
[19:18:12 CEST] <JEEB> right, if you want to create a thing a la "libffmpeg.so" then you should take a look at the patchwork/mailing list
[19:18:20 CEST] <JEEB> there recently was a patch posted for that purpose :P
[19:18:32 CEST] <dbogdanov> In that thread somebody proposed a patch, but it seems to be an ugly workaround.
[19:18:46 CEST] <JEEB> anyways, on ARM things seem to work for me just fine :P
[19:18:50 CEST] <dbogdanov> why won't --enable-pic work?
[19:19:26 CEST] <JEEB> I don't know, it has worked for me so far :P otherwise VLC's contrib system wouldn't work either
[19:19:59 CEST] <iive> dbogdanov: are you using recent ffmpeg ?
[19:19:59 CEST] <dbogdanov> I am building with ffmpeg-2.8.12
[19:45:56 CEST] <dbogdanov> Solved that by adding -Wl,-Bsymbolic flag to linker
[19:46:00 CEST] <dystopia_> is there anyway to set force-cfr=1 with a copy?
[19:46:09 CEST] <dbogdanov> Thanks, JEEB
[19:46:25 CEST] <dystopia_> ffmpeg -i %input% -acodec copy -vcodec copy out.mkv
[19:46:37 CEST] <dystopia_> ^input = cfr, output=vfr
[19:49:58 CEST] <furq> dystopia_: is the input an mp4
[19:50:35 CEST] <furq> some tools will show 23.97/29.97fps material in mkv as vfr because the frame timings aren't constant
[19:52:48 CEST] <dystopia_> in put was hevc .ts
[19:54:38 CEST] <furq> the output probably isn't actually vfr then
[19:54:58 CEST] <furq> i mean technically it is but it's as close as matroska can get to the input framerate
[20:03:35 CEST] <JEEB> and mpeg-ts is limited to 90 kilohertz in timestamps as well
[20:03:41 CEST] <JEEB> fun times
[21:01:45 CEST] <_blinsay> hey y'all, i'm having some issues with the concat demuxer producing corrupt output with mp4s/h.264
[21:02:40 CEST] <_blinsay> the two videos i'm trying to combine both seem to have have the same framerate/encoding and all that jazz
[21:03:25 CEST] <_blinsay> using a -filter_complex with the concat filter and the same two produces correct output
[21:04:04 CEST] <durandal_1707> corrupt in what sense?
[21:04:28 CEST] <_blinsay> the video doesn't play smoothly, blocks of solid color start appearing in it
[21:07:07 CEST] <_blinsay> https://www.dropbox.com/s/9fwdkje4gdkk4tq/corrupt_moon.png?dl=0
[21:30:42 CEST] <cryptodechange> Are there any filters that can correct 'shaky' footage, clearly taken from a film?
[21:31:13 CEST] <cryptodechange> I have applied some slight degraining to reduce bitrate, but it has made the wobble from whatever they used to convert from original film more apparent
[21:44:08 CEST] <Dan203> I'm upgrading some software from using the v2 libs to v3. I'm trying to stamp out some of the depreciated stuff. But one issue I'm running in to is in the muxer. In the code I call avformat_new_stream to add a stream to the formatcontext, then I use the avstream->codec to set the various options I need for the codeccontext. However there is a warni
[21:44:09 CEST] <Dan203> ng in v3 that the codec pointer is depreciated. So what is the new way to get the codeccontext for a avstream?
[21:46:20 CEST] <Mavrik> Dan203, codecpar I think
[21:50:05 CEST] <Dan203> Mavrik, that doesn't have all of the same options as CodecContext. Plus, according to the comments, if you call avformat_new_stream you're suppose to call avcodec_close on the created context. I can't do that unless I have some way to get the conext
[22:22:00 CEST] <c7j8d9> Anyone knowledgeable in colorspace? Converting an VP9.2 video to HEVC 10bit I get flat colors with bt2020nc and closer to original colors with bt2020c. Are there better settings for HDR?  (ffmpeg -hwaccel cuvid -i "HDR Input" -c:v hevc_nvenc -pix_fmt p010le -colorspace bt2020nc -color_primaries bt2020 -color_trc smpte2084 -rc constqp -qp 16 -c:a ac3 "Output.mp4")
[22:22:23 CEST] <JEEB> Dan203: git grep "from_context" doc/examples/
[22:22:41 CEST] <JEEB> the examples have plenty of ways to get codec parameters from an avstream etc
[22:23:53 CEST] <JEEB> c7j8d9: the question is how you're dealing with your content and what is the input/output
[22:24:12 CEST] <JEEB> (also cuvid can be fscking with you just as fine as well)
[22:27:11 CEST] <c7j8d9> Can you explain "dealing with your content"?
[22:27:35 CEST] <c7j8d9> Do you know the difference between bt2020 constant and non constant?
[22:27:46 CEST] <JEEB> in general yes, constant and non-constant luminance
[22:27:51 CEST] <JEEB> most content is NCL because of course
[22:28:06 CEST] <JEEB> that should be in the input metadata though, not a thing for any sort of debate
[22:28:50 CEST] <JEEB> what I'm trying to say is tell us what you exactly want to do, and then we go through the chain of events
[22:29:54 CEST] <c7j8d9> I downloaded vp9.2 video from youtube to play on my tv in hevc hdr10 since it won't play the vp9.2 file
[22:30:18 CEST] <JEEB> ok, so you actually do not want to do any conversions and just want to re-encode it
[22:31:23 CEST] <c7j8d9> yes...am I forcing conversions by specifying colorspace, primaries and trace?
[22:31:59 CEST] <JEEB> those are just metadata forcing things as far as I know, unless they have some special meaning with that specific HW encoder
[22:32:37 CEST] <JEEB> now, what colorspace values are you getting from the input and what sort of input is given by the HW decoder? also, does that HW decoder result go through some really insane conversion logic between the input and output. -v debug generally makes the thing spam a whole lot more but you should be able to see if any insane filter chains are going on
[22:33:24 CEST] <JEEB> post a full -v debug log or so on pastebin.com (or anything similar) and link here
[22:34:14 CEST] <paveldimow> Hi, can I analyze mp4 file so I can find what's the key frame interval?
[22:34:57 CEST] <JEEB> L-SMASH's boxdumper or ffprobe's -show_frames or -show_packets with limitation on the video track
[22:35:28 CEST] <JEEB> you can combine that with the -of json output to make it more digest'able by a script if you want to script it
[22:35:47 CEST] <paveldimow> JEEB: You are the king!
[22:36:35 CEST] <durandal_170> he is little peasant in field
[22:38:46 CEST] <paveldimow> Well he helped me many times before, so for me he is a king :)
[22:43:12 CEST] <c7j8d9> JEEB: is this enough info? https://pastebin.com/Mrwxqcgk
[22:44:05 CEST] <JEEB> [auto_scaler_0 @ 00000000055b9560] picking yuv420p out of 2 ref:yuv420p10le alpha:0
[22:44:08 CEST] <JEEB> [auto_scaler_0 @ 00000000055b9560] w:3840 h:2160 fmt:yuv420p10le sar:0/1 -> w:3840 h:2160 fmt:yuv420p sar:0/1 flags:0x4
[22:44:11 CEST] <JEEB> my condolences :P
[22:44:26 CEST] <JEEB> oh, that's ffplay
[22:44:29 CEST] <JEEB> why are you doing that?
[22:44:42 CEST] <JEEB> there's no way ffplay will play that sort of content correctly
[22:45:23 CEST] <c7j8d9> sorry...getting my feet wet with ffmpeg
[22:45:34 CEST] <JEEB> use latest mpv that can tone map down to SDR if you want a "proper" rendering of HDR content
[22:45:42 CEST] <c7j8d9> do if ffmpeg -i input -v debug?
[22:46:11 CEST] <JEEB> (although since tone mapping is not standardized in any way you cannot use it too much as a 'reference')
[22:46:28 CEST] <JEEB> (since all hardware and software will be doing it differently)
[22:46:44 CEST] <JEEB> c7j8d9: yes the idea was to get your ffmpeg command with your parameters - with the added -v debug in there
[22:46:51 CEST] <JEEB> so that the verbosity level was higher
[22:47:35 CEST] <c7j8d9> oh...when I convert? I was way off
[22:48:21 CEST] <c7j8d9> is mpv different then mpc?
[22:48:28 CEST] <JEEB> yes
[22:49:09 CEST] <JEEB> mpv is 100% open source (as opposed to mpc using the DShow media framework and whatever you have registered there), and has the least retarded video rendering framework that's available in any open source video player as far as I know
[22:49:17 CEST] <JEEB> lachs0r does windows builds
[22:49:27 CEST] <JEEB> https://mpv.srsfckn.biz/
[22:49:40 CEST] <wolfy__> Hi! What is the best approach to perform byte seeking when seek via timestamp (by using av_seek_frame()) is not available? In my case, it is feasible to preprocess the input video by iterating through all AVFrames. I read that AV_SEEK_BYTE doesn't always work.
[22:49:43 CEST] <wolfy__> I tried to use the approach described in the link below but I did not succeed, I populated a (timestamp -> byte) map, such that "byte" is the byte offset of the last read key frame while preprocessing the video. The frame that I obtain after performing the seek comes way before the target, there are lots of key frames between them. https://stackoverflow.com/a/3062994/351527
[22:50:22 CEST] <JEEB> c7j8d9: you can just extract and test by drag and dropping a file on top of mpv.exe. if you want hwdec to be utilized you will have to add --hwdec=dxva2-copy
[22:51:03 CEST] <JEEB> "normal" dxva2 will go through funky automated dxva2 routines which will not give the original YCbCr to the renderer
[22:59:23 CEST] <c7j8d9> JEEB: https://pastebin.com/G6RLEG1v
[23:01:38 CEST] <c7j8d9> this time the color looks the same even using bt2020nc
[23:03:51 CEST] <JEEB> that looks like swdec for the VP9, which should in theory be more less of "what the fuck is it doing"
[23:04:04 CEST] <JEEB> what I am interested in is how the yuv420p10 conversion is being done
[23:04:27 CEST] <JEEB> as in, yuv420p10 to p010le
[23:04:35 CEST] <JEEB> which should just be byte packing
[23:04:53 CEST] <JEEB> (yuv420p10 is fully planar, p010le is a semi-packed format)
[23:08:28 CEST] <JEEB> also do double-check if the nvenc hevc encoder actually writes the metadata
[23:08:53 CEST] <JEEB> if you ffprobe the file that was generated, if you get the correct colorspace values and MaxCLL/MaxFALL etc
[23:17:03 CEST] <c7j8d9> JEEB: https://pastebin.com/zzUSChy9
[23:19:26 CEST] <JEEB> try with -v debug although it seems like the additional metadata was not passed through the nvidia encoder
[23:19:43 CEST] <JEEB> basics are there, though
[23:19:45 CEST] <JEEB> tv, bt2020nc/bt2020/smpte2084
[23:20:49 CEST] <c7j8d9> me/ being an impatient person quit the encoding early to paste the output
[23:21:02 CEST] <JEEB> that should be OK as you can decode it fine
[23:21:10 CEST] <JEEB> the extradata thing should be written at that point anyways
[23:21:59 CEST] <JEEB> but yes, that result agrees with what I see in the nvenc hevc encoder, it just doesn't utilize the additional colorspace metadata
[23:22:22 CEST] <c7j8d9> https://pastebin.com/hCPM3apy
[23:22:55 CEST] <JEEB> so there's two possibilities: fuckery in the yuv420p10 -> p010le conversion (which should be lossless in theory since the data should be the same, just located differently in the buffers) or it's just the usual HDR playback bullshit.
[23:23:47 CEST] <JEEB> yea, that's as expected now. since the nvenc hevc encoder doesn't handle the additional values.
[23:24:05 CEST] <c7j8d9> additional colorspace metadata being the luminance and macll maxfall stuff?
[23:24:35 CEST] <c7j8d9> the usual HDR playback BS is what?
[23:25:07 CEST] <JEEB> that everything can play things differently yet they could all be correct
[23:25:19 CEST] <JEEB> due to things like tone mapping etc not being standardized
[23:25:40 CEST] <JEEB> so your TV, mpv and random other software could all claim they're correct at playback but they might not look similar
[23:26:17 CEST] <JEEB> ok, libx265 doesn't seem to utilize the side data containing the maxfall/maxcll etc stuff
[23:26:20 CEST] <JEEB> either
[23:26:28 CEST] <Mavrik> Hmm, interesting question here - how does that work in terms of HDMI?
[23:26:52 CEST] <Mavrik> If you have a HLG/HDR10/Dolby HDR content, do AVRs break that/need explicit support?
[23:27:13 CEST] <JEEB> Mavrik: HDMI has various values. I know a lot of hardware just passes the YCbCr as-is with the required metadata
[23:27:42 CEST] <JEEB> and other things convert to RGB and then note it as SMPTE ST.2084 / BT.2020
[23:28:48 CEST] <Mavrik> So for example you have an AVR that doesn't support HLG, but you have a player and TV that does - is metadata standard and gets passed through, or does it get stripped?
[23:28:57 CEST] <Mavrik> Can't really find documentation on all that :/\
[23:29:05 CEST] <JEEB> what was an AVR again?
[23:29:29 CEST] <Mavrik> Oh, AV Receiver
[23:29:41 CEST] <Mavrik> Or any other such device that does switching or audio stripping
[23:30:35 CEST] <JEEB> right. if it isn't doing "dumb" passthrough or cannot handshake the correct metadata it might just ASDF ASDF - or the feeding side just wouldn't be able to set the correct values as the protocol solving wouldn't finish
[23:31:15 CEST] <JEEB> not that I'm any good at HDMI specifics - the last time I tried to look into how you could control what a HDMI device would output led to a lot of pain and giving up
[23:31:59 CEST] <Mavrik> Yeah, that's the part I can't find any good info on - what to receivers actually do with HDMI signal
[23:32:13 CEST] <JEEB> so at this point I think the only way to test is to find a GPU+screen that lets you use the new D3D HDR APIs
[23:32:26 CEST] <JEEB> and then in actual full screen you can switch to SMPTE ST.2084/BT.2020
[23:32:38 CEST] <JEEB> since you have full control of the full screen environment
[23:32:52 CEST] <JEEB> (there previously were nvidia-specific APIs for this)
[23:33:17 CEST] <Mavrik> hmm, I have a nVidia 970 connected through an AVR to a 4K/HDR TV, so I guess I could go look for test cases
[23:33:17 CEST] <JEEB> but yea, depends on if the protocol handshakes pass with such stuff.
[23:33:40 CEST] <JEEB> and of course you'd have to make sure that it works correctly without the AVR in the middle
[23:33:54 CEST] <JEEB> which can be fun to decide as well :D
[23:33:56 CEST] <Mavrik> This whole HDR mess seems to be worse than the usual protocol problems :/
[23:34:02 CEST] <JEEB> yes
[23:34:14 CEST] <Mavrik> I wonder what kind of BS will Apple do on their new AppleTV
[23:34:14 CEST] <JEEB> tone mapping not being specified alone leads to quite different results
[23:34:19 CEST] <Mavrik> Fourth standard? :P
[23:35:48 CEST] <chance> Hi, I am trying to find a command that shows me the max bitrate of a video file. I have searched to hard to find this function, but no luck. Do any of you guys have ideas?
[23:36:15 CEST] <JEEB> chance: the maximum bit rate is always dependant on over what you calculate it
[23:36:25 CEST] <Mavrik> Yeah, that's what I wanted to ask - what's the window
[23:36:35 CEST] <chance> Could you explain what that means?
[23:36:37 CEST] <JEEB> usually you have a buffer size over which your maxrate would be calculated
[23:36:44 CEST] <JEEB> otherwise your question makes no sense
[23:37:03 CEST] <chance> Okay, so you sample small parts of the video?
[23:37:19 CEST] <Mavrik> Yes, and the depending on how big your part is, that's what your number will be
[23:37:25 CEST] <Mavrik> So it'll differ
[23:37:41 CEST] <chance> What's the best way to estimate this then?
[23:38:01 CEST] <JEEB> depends
[23:38:10 CEST] <JEEB> I mean, what kind of buffer is relevant to you
[23:38:31 CEST] <c7j8d9> thanks JEEB ... good food for thought
[23:38:57 CEST] <chance> I want to make sure "VOD content the peak bit rate SHOULD be no more than 200% of the average bit rateaccording to HLS standards
[23:39:10 CEST] <JEEB> yes, but that is always according to your buffer size
[23:39:22 CEST] <JEEB> usually you set maxrate and bufsize when encoding to keep your encodes within such parameters
[23:39:43 CEST] <chance> okay thank you
[23:39:50 CEST] <Mavrik> What's a reasonable default buffer size?
[23:40:00 CEST] <JEEB> or if the HLS specification defines the way of calculating the peak bit rate, that is the word
[23:40:12 CEST] <JEEB> as far as I know, it doesn't
[23:41:47 CEST] <DHE> there are distinct AVERAGE-BITRATE (-b) and BITRATE (-maxrate) parameters in the playlist
[23:42:06 CEST] <DHE> that's how  I interpret them
[23:42:48 CEST] <JEEB> yes, but that still doesn't set the buffer size
[23:42:59 CEST] <JEEB> over which  to calculate the maxrate
[23:43:18 CEST] <DHE> true. I'm not sure what the optimal value for that would be
[23:43:31 CEST] <chance> I am using a Bitrate Viewer tool which shows this: https://www.filepicker.io/api/file/zi6olrRvShy29sHtaIvW?signature=ac6eadf57f501345705f7ac1af5d4065fd203a410471f4d8e8c20445488085b0&policy=eyJleHBpcnkiOjE1MDMzNTQ1MjN9
[23:43:57 CEST] <JEEB> chance: the problem with those kinds of tools is that they are very opaque regarding what they mean with the values
[23:44:10 CEST] <JEEB> are they calculating over a buffer? if yes, what sort of buffer?
[23:44:22 CEST] <chance> Hmmm.. I will check their website
[23:44:33 CEST] <JEEB> or is it a single packet's bit rate (duration of packet and amount of bits used)
[23:44:43 CEST] <c7j8d9> Is there any benefit from converting bt709 to bt2020?
[23:45:09 CEST] <JEEB> c7j8d9: not really. you lose compatibility and you're not going to be doing re-grading the stuff anyways
[23:45:30 CEST] <c7j8d9> can you regrade with ffmpeg?
[23:45:55 CEST] <JEEB> most likely not, although there's a plethora of filters. just that not many of them deal in float
[23:46:25 CEST] <JEEB> which is pretty much required for keeping the over/underflowing values and the precision
[23:46:33 CEST] <JEEB> when doing something like color grading :P
[23:46:49 CEST] <JEEB> I have at least one UHD BD thing where the guys specifically said they took a BT.709 master and then made up the BT.2020/SMPTE ST.2084 grading
[23:47:07 CEST] <JEEB> (and let's not even talk about the fact that the master was 1080p)
[23:47:19 CEST] <c7j8d9> Tekno3D?
[23:47:49 CEST] <Mavrik> hmm
[23:47:59 CEST] <JEEB> nope, in-house by Q-Tec I think
[23:49:00 CEST] <c7j8d9> Well I am kinda curious about the same thing. Taking 1080p blurays regrading to bt2020 and 10.000nit upscaling to 4k
[23:49:18 CEST] <JEEB> doesn't make any sense
[23:49:47 CEST] <JEEB> if you had a master it'd still be shitty but at least you'd have to make the original author give his OK on your re-grading
[23:50:05 CEST] <JEEB> the upscale is just what it is, might be useful for future encoders if you did it sanely and your master was 4:4:4
[23:50:14 CEST] <JEEB> (since you could keep the 1080 worth of chroma in 2160p
[23:50:29 CEST] <JEEB> re-encoding blu-rays like that just ain't making sense
[23:50:37 CEST] <JEEB> but I bet people will do it
[23:51:06 CEST] <JEEB> just like in the 2000s we had people applying dozens of filters on their DVD/HDTV/BD rips
[23:54:31 CEST] <c7j8d9> they are "creating" 4k hdr content that doesn't exist and claim to be making better 4k hdr content than exists.
[23:55:05 CEST] <c7j8d9> https://www.youtube.com/watch?v=HI06dDUEY98&list=PLXmpoI8kKMrybV4wpba9NJ-hwH_lbo_43&index=3
[23:56:32 CEST] <c7j8d9> their stuff looks great with madvr but not that much better on my tv
[23:57:25 CEST] <JEEB> well at that point it's no longer the original content and it's just someone's interpretation of how it should look as opposed to how the actual mastered content should look
[23:57:45 CEST] <c7j8d9> true
[23:58:06 CEST] <JEEB> I mean, similar shit has been done by GPU vendors for over 10 years now
[23:58:13 CEST] <JEEB> they will inject shit into your DXVA2 chain
[23:58:25 CEST] <JEEB> and do color filtering etc
[23:58:54 CEST] <JEEB> this is just a fancy version of that with most likely some sort of human oversight to try and make it "look good" with the tone mapping they're applying
[23:59:33 CEST] <c7j8d9> they are trying to make things look more "realistic" colors, shadows, deep blacks
[23:59:46 CEST] <JEEB> well, yes. making shit up
[00:00:00 CEST] --- Tue Aug 22 2017