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

[burek]

[00:14:31 CEST] <void09> where I can I see some refference psnr and ssim and such scores for encoders?
[00:16:49 CEST] <kepstin> void09: there's not really any such thing? the numbers vary so much between encoder options and even over time as encoders develop...
[00:17:31 CEST] <void09> I did those tests for my encodes.. but I have no idea what they mean
[00:17:53 CEST] <void09> PSNR score = 48.584059 SSIM score = 0.997152
[00:17:54 CEST] <kepstin> modern encoders typically even have psnr/ssim optimizations that make the scores higher but potentially reduce perceptual quality
[00:18:25 CEST] <void09> is that "good" ? :)
[00:18:59 CEST] <kepstin> void09: the numbers are only really useful in comparison to other numbers
[00:19:15 CEST] <kepstin> so if you do two encodes and compare the psnr, you can see that one encode has better psnr than another
[00:19:31 CEST] <kepstin> which may or may not correspond to one encode looking better than another
[00:19:32 CEST] <void09> yeah i did two encodes, one with 8 bit encode, the other with 10bit , of the same 8 bit source
[00:19:41 CEST] <void09> 10bit one has lower scores yet it appears to look better to me
[00:21:20 CEST] <kepstin> presumably you had to convert the 10bit back to 8bit to do the psnr comparison, and that usually involves dither, which is literally adding noise
[00:21:31 CEST] <kepstin> so, yeah.
[00:23:13 CEST] <kepstin> if you think the 10bit looks better why are you even bothering to measure anyways? looking better to you is the thing that matters in the end.
[00:23:27 CEST] <void09> somebody asked me to
[00:23:34 CEST] <void09> but I am not an expert.
[00:24:36 CEST] <void09> can't really tell much difference except the 10bit one suffers from minimal colour banding, whereas in the 8bit one it is rather obvious in a certain part of the video
[00:25:23 CEST] <void09> so that's why the lower scores.. 10bit to 8bit to do comparison with the 8bit source, which involves dither ?
[00:25:27 CEST] <void09> this is the ffmpeg line i used
[00:25:47 CEST] <void09> ffmpeg -i 10bit-257.mkv -i 4244frameBluray.mkv -lavfi libvmaf="psnr=1:ssim=1:ms_ssim=1" -f null -
[00:27:06 CEST] <kepstin> yeah, you can't compute the comparisons between different bit depths, so one or the other would have to be converted. hard to say what exactly the numbers mean in that circumstance
[00:27:20 CEST] <void09> hm true..
[00:27:31 CEST] <void09> but which one was converted to which ?
[00:27:40 CEST] <void09> what if the source was converted to 10bit ?
[00:27:50 CEST] <kepstin> would need to see that command run with -v verbose to see the auto-inserted conversions to confirm
[00:27:58 CEST] <kepstin> but it probably upconverted the source to 10bit
[00:28:11 CEST] <void09> but even then, you'd have a slightly different colour spectrum I presume
[00:28:28 CEST] <void09> the encode was done with constant quality, so they should be about the same quality
[00:28:41 CEST] <kepstin> what encoder? x264?
[00:28:43 CEST] <void09> the 10bit one turned out 4% smaller
[00:28:44 CEST] <void09> no, av1
[00:29:00 CEST] <kepstin> hmm, i know nothing about av1 encoders
[00:29:13 CEST] <kepstin> but in other encoders the constant quality modes aren't comparable between bitrates
[00:29:20 CEST] <kepstin> i'd expect most av1 encoders to be similar
[00:29:41 CEST] <kepstin> aren't comparable between bit depths*
[00:30:16 CEST] <void09> right.
[00:30:27 CEST] <void09> testing with another av1 yielded a much larger file for 10bit
[00:30:33 CEST] <kepstin> anyways, for actual playback that a person would see, the 10bit video is typically downconverted to 8bit and dithered - since 10bit displays are currently very rare
[00:30:50 CEST] <void09> hm I should get one
[00:30:59 CEST] <void09> just for this purpose :)
[00:31:37 CEST] <void09> who does that dithering?
[00:31:41 CEST] <void09> when playing a 10bit file
[00:31:50 CEST] <void09> where does it happen
[00:32:17 CEST] <kepstin> typically video player
[00:33:01 CEST] <kepstin> e.g. mpv has 8-to-10bit conversion with dither as part of the yuv to rgb conversion that it uses for pc playback, and that runs on gpu shaders on supported machines.
[00:36:48 CEST] <kepstin> it's looking like most 10bit+ consumer displays are gonna be hdr displays with expanded color space, so i doubt they'd be capable of playback of 10bit non-hdr video anyways.
[00:37:15 CEST] <void09> i thought hdr was 10bit
[00:37:39 CEST] <void09> or does hdr need at least 10bit
[00:37:53 CEST] <kepstin> hdr and 10bit are orthagonal. it's just that since hdr uses a wider brightness range, you get really bad banding unless you increase the bit depth
[00:39:44 CEST] <void09> how does one find true 10 bit displays?
[00:40:17 CEST] <void09> as in, not the ones that use that pixel flashing trick to simulate extra colorus
[00:41:01 CEST] <kepstin> i dunno, i've never seen once. I suspect they're mostly sold for stuff like medical imaging?
[00:41:36 CEST] <kepstin> it's kind of surprising how few displays are actually 8-bit, there's a lot of low end monitors that are really 6bit :)
[00:47:35 CEST] <kepstin> interesting, the vesa displayhdr specs requires that monitors accept 10bit signals and do 10bit processing, but allows them to use 8bit panels with dithering.
[00:49:11 CEST] <der_richter> use your comparison shopping site of your choice and filter for 10bit without FRC, i guess
[00:51:18 CEST] <der_richter> https://skinflint.co.uk/?cat=monlcd19wide&xf=11959_10bit+(10bit+ohne+FRC)&sort=p#productlist
[00:52:55 CEST] <kepstin> hmm, i doubt that actually worked, i'm pretty sure most of the cheaper monitors in that list are 8bit panels without mentioning frc :)
[00:52:55 CEST] <void09> I doubt that filtering produces accurate results. It's only as good as the entries are complete/correct in the database
[00:53:00 CEST] <void09> lol
[00:53:06 CEST] <der_richter> they are
[00:53:43 CEST] <der_richter> but really someone who is looking for quality and buys a dead cheap monitor...
[00:54:18 CEST] <der_richter> it help weeding out a lot of the shit at least and one can cross check some of the more expensive ones with other sources
[00:54:30 CEST] <void09> https://skinflint.co.uk/dell-ultrasharp-up3216q-210-aguo-210-agur-a1329898.html?hloc=uk
[00:54:41 CEST] <void09> this one is :) 10bit (10bit without FRC). so they actually exist
[00:55:45 CEST] <void09> https://skinflint.co.uk/iiyama-prolite-xu2395wsu-b1-a1853295.html?hloc=uk
[00:55:52 CEST] <void09> but this one says the same.. 10bit with no frc
[00:56:26 CEST] <der_richter> >expecting a dead cheap display to...<
[00:56:51 CEST] <der_richter> obviously it needs some commong sense
[00:56:58 CEST] <kepstin> note that you might need to also get a high end professional graphics card (e.g. quadro or radeon pro) to get driver support to output 10bit to the monitor - although that'll hopefully change soon for consumer hdr monitors.
[00:57:46 CEST] <der_richter> https://skinflint.co.uk/samsung-u32h850-lu32h850umuxen-a1622028.html?hloc=uk i believe this one is also 10bit without frc
[00:58:16 CEST] <void09> what, no 10bit output on high end gaming gpus ? ;o
[00:58:40 CEST] <kepstin> in older generations it was arbitrarily driver limited :/
[00:59:10 CEST] <void09> oh, a driver limitation
[01:03:18 CEST] <kepstin> but yeah, note that these hdr monitors map the 10bit to a wider color range - so for playing non-hdr video, it's won't use the full color range of the monitor, which means it's not making full use of the extra bit depth :) should still be better than 8bit tho.
[01:03:59 CEST] <kepstin> unless you don't have it color managed properly -  in which case it will use the full range of the monitor, and the video will look too contrasty and saturated.
[05:50:30 CEST] <kebabas> hello anyone here?
[05:51:21 CEST] <kebabas> im encoding hevc hdr video to dnxhr 444 but im losing hdr settings. Im using command line like this: ffmpeg -i input.mkv -c:v dnxhd -vf "scale=4096:2160,fps=30000/1001,format=yuv444p10le" -profile:v dnxhr_444 outputas.mov
[05:51:44 CEST] <kebabas> is here any way to make it dnxhr hdr? because original content is in hdr
[06:10:27 CEST] <kebabas> Hey @Buster maybe you can help me with ffmpeg?
[13:07:06 CEST] <urdne> hello fellows, i'm trying to batch convert some videos from vp8 to mp4 on windows and the tactic of googling for what to copy/paste has led me to several deadends. any assistance? https://pastebin.com/3mcwdkvB
[13:07:38 CEST] <urdne> i figured it would be as simple as changing filename.webm filename.mp4 to *.webm *.mp4 but alas, nothing ever is, is it
[13:14:53 CEST] <c_14> urdne: try adding -c:v libx264
[13:15:22 CEST] <c_14> I'm not entirely sure why, but it looks like it's trying to encode vp8 into mp4 (which won't work)
[13:15:34 CEST] <c_14> wait, nvmd
[13:15:44 CEST] <c_14> it thinks the ; is part of the file extension
[13:16:17 CEST] <c_14> I don't think you need the "; done" in batch anyway?
[13:17:39 CEST] <urdne> i've tried another copy/paste solution https://stackoverflow.com/questions/43695545/ffmpeg-batch-convert-for-windows and it worked, danke c_14
[15:32:09 CEST] <kebabas> Hello how to encode video and leave as HDR format im using this command ffmpeg -i input.mkv -c:v dnxhd -vf "scale=4096:2160,fps=30000/1001,format=yuv444p10le" -profile:v dnxhr_444 outputas.mov
[15:35:51 CEST] <kebabas> please help me someone :)
[16:10:22 CEST] <kebabas> hello anyone heres?
[16:21:43 CEST] <RonaldsMazitis> hello
[16:21:52 CEST] <RonaldsMazitis> I am trying to use ffmpeg on windows 7
[16:22:40 CEST] <RonaldsMazitis> ffmpeg -framerate 24 -i img%03d.png output.mp4 I have images named img000.png img022.png etc
[16:22:53 CEST] <RonaldsMazitis> but cmd is saying there is no file named
[16:22:55 CEST] <RonaldsMazitis> like that
[16:30:17 CEST] <RonaldsMazitis> I am trying to make "slideshow"
[16:30:22 CEST] <RonaldsMazitis> 1 images per second
[16:33:52 CEST] <kebabas> seems here is hard to get support from experienced users :(
[16:34:06 CEST] <RonaldsMazitis> Could find no file with path 'img%03d.png' and index in the range 0-4 img%03d.png: No such file or directory
[16:34:13 CEST] <RonaldsMazitis> img000.png.png  img011.png.png
[16:38:00 CEST] <DHE> .png.png ?
[16:39:15 CEST] <RonaldsMazitis> ok that was mistake
[16:39:24 CEST] <RonaldsMazitis> so how do I get
[16:39:30 CEST] <RonaldsMazitis> one image per second
[16:41:18 CEST] <RonaldsMazitis> ok
[16:41:23 CEST] <RonaldsMazitis> I understood
[16:42:23 CEST] <DHE> also it's expected there will be 000, 001, 002, 003, 004, 005, etc. if it skips straight from 000 to 011 that could be a problem
[16:43:11 CEST] <DHE> ffmpeg -framerate 1 -i "img%03d.png.png" [...]
[16:44:08 CEST] <kebabas> @DHE do you understand about encoding to dnxhr format?
[16:44:34 CEST] <DHE> no
[16:49:26 CEST] <RonaldsMazitis> my mp4 is not readablet
[16:49:28 CEST] <RonaldsMazitis> by phone
[16:49:38 CEST] <RonaldsMazitis> and program does not take avi
[16:52:09 CEST] <DHE> RonaldsMazitis: ffmpeg [...]  -movflags faststart -pix_fmt yuv420p output.mp4
[16:55:45 CEST] <RonaldsMazitis> height not divisible by 2 (272x83)
[16:59:44 CEST] <DHE> sigh...
[17:41:55 CEST] <RonaldsMazitis> ffmpeg -framerate 1 -i img%03d.png output.mp4
[17:42:39 CEST] <RonaldsMazitis> fails
[17:42:51 CEST] <RonaldsMazitis> file does not plays
[17:45:09 CEST] <pzich> RonaldsMazitis: what are you playing it with? you probably want to change the pix_fmt
[17:45:38 CEST] <th3_v0ice> Some time ago you guys told me that muxer is able to handle one timestamp wraparound and that it will basically not wrap timestamps around next time wraparound happens. Is this fixed in the latest release of library?
[17:49:42 CEST] <ddubya> th3_v0ice, no idea about that, but what is causing the wraparound? Maybe it can be avoided
[17:50:10 CEST] <RonaldsMazitis> pzich
[17:50:12 CEST] <RonaldsMazitis> how
[17:50:13 CEST] <RonaldsMazitis> ?
[17:50:31 CEST] <RonaldsMazitis> it kinda worked but I choosed wrong color background
[17:50:35 CEST] <RonaldsMazitis> now it is stuck
[17:52:27 CEST] <pzich> stuck?
[17:52:38 CEST] <pzich> something like -pix_fmt yuvj420p
[17:52:47 CEST] <pzich> or yuv420p depending on how old your ffmpeg is
[17:53:38 CEST] <RonaldsMazitis> did not work
[17:54:17 CEST] <pzich> what are you playing it with?
[17:54:28 CEST] <RonaldsMazitis> ffmpeg
[17:54:52 CEST] <RonaldsMazitis> images are 271x85
[17:54:53 CEST] <RonaldsMazitis> big
[17:55:20 CEST] <RonaldsMazitis> I need one image per second
[17:55:44 CEST] <th3_v0ice> ddubya, timestamps wraparound in udp.
[17:55:45 CEST] <pzich> I think you're going to want your resolution to be a multiple of 2. ffmpeg is probably already adjusting for that though
[17:56:20 CEST] <th3_v0ice> Do you know where is the code that is handling the wraparound in mpegts muxer?
[17:56:20 CEST] <pzich> does your file play back in vlc or any other app?
[17:57:13 CEST] <RonaldsMazitis> ffmpeg -framerate 0.2 -i img%03d.png -vf fps=10 -pix_fmt yuv420p output.mp4
[17:57:19 CEST] <RonaldsMazitis> [libx264 @ 0x1cfa340] height not divisible by 2 (272x83)
[17:57:27 CEST] <pzich> correct
[17:57:39 CEST] <pzich> your height is 85 and 85 is not divisible by 2
[17:58:00 CEST] <pzich> well actually ffmpeg is saying 272x83, are they that or 271x85?
[18:00:55 CEST] <RonaldsMazitis> okay
[18:00:57 CEST] <RonaldsMazitis> I changed
[18:01:03 CEST] <RonaldsMazitis> still my video does not palys
[18:01:04 CEST] <RonaldsMazitis> plays
[18:01:57 CEST] <RonaldsMazitis> ffmpeg -framerate 1 -i img%03d.png now worked
[18:02:06 CEST] <RonaldsMazitis> but my video is only one frame
[18:02:34 CEST] <pzich> and your images are a continuous sequence of numbers like img001.png?
[18:02:39 CEST] <RonaldsMazitis> yeah
[18:02:54 CEST] <RonaldsMazitis> from img001 to img051
[18:03:06 CEST] <ddubya> th3_v0ice, nope. I do know that the concat function of ffmpeg can deal with it, so it is possible. Maybe using a bitstream filter or modifying packets directly via the api
[18:04:44 CEST] <th3_v0ice> I am using the API :)
[18:04:44 CEST] <pzich> RonaldsMazitis: hmm, this says it expects to start at 0, although if it's making a video of anything it seems like it's finding them https://en.wikibooks.org/wiki/FFMPEG_An_Intermediate_Guide/image_sequence#Filename_numbering
[18:04:53 CEST] <pzich> maybe try -start_number 1?
[18:05:35 CEST] <pzich> might also be worth trying the glob pattern
[18:08:23 CEST] <ddubya> th3_v0ice, ok so what you need to do is look for the packet dts/pts to wrap, and modify the values to make it continous
[18:08:31 CEST] <ddubya> avpacket that is
[18:08:51 CEST] <ddubya> before passing packet to the muxer
[18:09:01 CEST] <RonaldsMazitis> ffmpeg -framerate 1 -pattern_type glob -i img%03d.png output.mp4
[18:09:07 CEST] <RonaldsMazitis> Could not find codec parameters for stream 0 (Video: png, none(pc)): unspecified size
[18:09:07 CEST] <RonaldsMazitis> Consider increasing the value for the 'analyzeduration' and 'probesize' options
[18:09:24 CEST] <RonaldsMazitis> help
[18:09:24 CEST] <RonaldsMazitis> me
[18:10:27 CEST] <RonaldsMazitis> ffmpeg -framerate 10 -pattern_type glob -i '*.jpg' -c:v libx264 -pix_fmt yuv420p out.mp4
[18:10:30 CEST] <RonaldsMazitis> this one works
[18:12:36 CEST] <th3_v0ice> ddubya, While I appreciate your help, this information is not helping :)
[18:13:28 CEST] <ddubya> do you require more details?
[18:14:25 CEST] <th3_v0ice> I have already done this, these DTS information wraps around at 34bits and mpegts timestamp is 33. My question is what is the FFmpeg doing to fix the wraparound from 34 to 33 bits first time.
[18:14:48 CEST] <ddubya> oic
[18:14:58 CEST] <ddubya> so it isn't at the packet level
[18:15:19 CEST] <th3_v0ice> Its on a muxer level.
[18:15:41 CEST] <ddubya> well mpeg streams have their own internal timestamps right
[18:16:22 CEST] <ddubya> the system layer has a different one
[18:18:02 CEST] <th3_v0ice> Packets have timestamps which are represented in stream timebase. Not sure about "system layer"
[18:19:07 CEST] <ddubya> Its my understanding that the elementary streams "ES" are packetized within the transport/system layer (TS) and there are different timestamps in each, though ideally they should be related
[18:19:23 CEST] <ddubya> The TS being the outside layer represented in AvPacket
[18:22:08 CEST] <th3_v0ice> Timestamps of those packets are just timestamps of AVPacket.
[18:22:17 CEST] <th3_v0ice> PES packet in case of MpegTS
[18:49:11 CEST] <ddubya> th3_v0ice, I didn't think that AVPacket timestamps could wrap around without causing a failure. Muxers want increasing values. You are saying it continues to work after wrapping around the first time? but no the second?
[18:50:38 CEST] <th3_v0ice> First wraparound is handled, timestamp continue from 90k to 150k. Then wraparound happens again, this time they are not continuing it basically breaks.
[18:57:05 CEST] <ddubya> can you segment the output to keep it from wrapping? Isn't the first wrap something like 26 hours?
[19:56:51 CEST] <Aelius> If I have a 239.76 fps video I want to convert to slow motion. I used the following command: -filter:v "setpts=24.0*PTS" -r 29.97
[19:57:02 CEST] <Aelius> where 239.76/8 = 29.97
[19:57:20 CEST] <Aelius> The output looks ok but I want to know if that was the best way to go about this
[19:59:07 CEST] <DHE> you might also try: ffmpeg -r 1 -i input.mp4 -c:v copy -an output.mp4    (intentionally strips out the audio track)
[19:59:28 CEST] <DHE> I think that's right
[20:01:45 CEST] <Aelius> -r 1 preserves the speed of the video and makes it 1fps
[20:02:04 CEST] <Aelius> ie it gives me a timelapse of 1 picture every second
[20:03:37 CEST] <Aelius> My goal is to slow down the video without losing any frames
[20:04:27 CEST] <Aelius> -r 1 skips 239 frames off every second :P
[20:05:46 CEST] <DHE> where you put the -r parameter matters
[20:05:53 CEST] <DHE> before -i it's treated as a framerate override on the input
[20:06:02 CEST] <DHE> after -i it's treated as an output framerate request
[20:06:13 CEST] <Aelius> ok
[20:08:44 CEST] <Aelius> yeah that works! thanks. But how portable is a 2fps video? Will browsers, social media sites, video players all handle it correctly?
[20:09:16 CEST] <furq> you probably want to set -r again after -i to set a more compatible output framerate
[20:09:33 CEST] <furq> as an output option it'll just duplicate frames to get the requested rate
[20:09:39 CEST] <Aelius> ok nice
[20:12:24 CEST] <DHE> yeah but I'm aiming for a fast no-transcode conversion. it should be as playable as the original, but keyframes will be quite rare affecting seeking
[20:14:43 CEST] <Aelius> would -r 2 strangely interfere with the fractional 239.76 source fps?
[20:17:13 CEST] <furq> not really
[20:17:36 CEST] <furq> it'd mean that the playback speed wouldn't be a clean fraction of the source, if that matters
[20:20:34 CEST] <kebabas> Hello anyone can help me with encoding to dnxhr and not losing hdr metadata info from file?
[20:20:59 CEST] <kebabas> im using this command ffmpeg -i input.mkv -c:v dnxhd -vf "scale=4096:2160,fps=30000/1001,format=yuv444p10le" -profile:v dnxhr_444 outputas.mov
[20:21:14 CEST] <kebabas> but on output im not getting bt2020 color
[20:24:32 CEST] <kepstin> my impression is that most of that info is stored as container-level metadata? It might be that ffmpeg doesn't know how to write that into mov
[20:27:10 CEST] <furq> you need to specify -colorspace/-color_trc/-color_primaries if you're reencoding
[20:27:26 CEST] <kebabas> how to do it ;D?
[20:27:32 CEST] <kebabas> im nab at this things
[20:29:59 CEST] <kepstin> kebabas: you take the list of options that furq mentioned, realize that they're command-line options for the ffmpeg tool, and then look them up in the docs https://www.ffmpeg.org/ffmpeg-codecs.html#Codec-Options to find out what values are accepted.
[20:30:45 CEST] <kebabas> problem is i tried different commands and even made reddit thread but still cant get ir correcct
[20:31:00 CEST] <kebabas> tried using scale=in_color_matrix=bt2020:out_color_matrix=bt2020
[20:31:05 CEST] <kebabas> but still cant get it right
[20:33:16 CEST] <kebabas> 1 guy said its possible to merge it later but tried with mkvmerge and still cant get ir right
[20:33:23 CEST] <kepstin> that said, it's unclear whether the dnxhd encoder actually does anything with those options?
[20:34:16 CEST] <kepstin> ah, the mov muxer should be using those
[20:34:22 CEST] <kepstin> to set metadata
[20:34:31 CEST] <kebabas> my original file is in hevc codec with hdr metadata, when i reencoding it to dnxhr im losing hdr metadata and dont know how to keep it
[20:35:47 CEST] <kebabas> here is file info
[20:35:48 CEST] <kebabas> https://pastebin.com/YkX7iSaX
[20:36:04 CEST] <kepstin> kebabas: may I suggest that you scroll your irc client up and re-read furq and my responses, where we tell you what to do?
[20:36:21 CEST] <kebabas> sorry i was loged off and im using web client
[20:36:27 CEST] <kebabas> i dont have history :((
[20:38:00 CEST] <furq> -color_primaries bt2020 -colorspace bt2020c -color_trc bt2020_10bit
[20:38:17 CEST] <furq> or -colorspace bt2020nc if that's what you want
[20:38:32 CEST] <furq> i assume that swscale is smart enough to keep the source primaries without being asked to
[20:38:37 CEST] <furq> but i don't actually know for sure
[20:39:29 CEST] <kebabas> ffmpeg -i input.mkv -color_primaries bt2020 -colorspace bt2020c -color_trc bt2020_10bit -c:v dnxhd -vf "scale=4096:2160,fps=30000/1001,format=yuv444p10le" -profile:v dnxhr_444 outputas.mov
[20:39:31 CEST] <kebabas> like this?
[20:39:58 CEST] <furq> probably
[20:40:16 CEST] <furq> i've only ever used it with h264/hevc though
[20:42:19 CEST] <kebabas> ok trying to encode for 100 time :D
[20:42:23 CEST] <kebabas> i hope its going work
[20:48:57 CEST] <kebabas> i did it and still not working :/
[20:49:01 CEST] <kebabas> shiiiiiet
[20:51:44 CEST] <kepstin> try a different codec maybe?
[20:52:13 CEST] <kebabas> furq: anyway thanks for help
[20:52:24 CEST] <kebabas> i want to use apple pro ress or dnxhr
[20:53:12 CEST] <kebabas> im trying now same commands with apple pro ress maybe its going work
[20:53:12 CEST] <kepstin> the prores encoders do at least look at the various color fields, unlike the dnxhd encoder. so it could be worth a try.
[21:10:51 CEST] <kebabas> funny thing, every new tip i find on google its always different command lines :D
[21:22:59 CEST] <kebabas> how to understand in media info
[21:23:00 CEST] <kebabas> Color primaries : BT.2020  colour_primaries_Original : BT.709  Transfer characteristics : PQ  transfer_characteristics_Original : BT.709  Matrix coefficients : BT.2020 non-constant  matrix_coefficients_Original : BT.709
[21:23:25 CEST] <kebabas> atleast im getting something with proress
[21:46:31 CEST] <pa[m]> funny, i was about to ask in here about color spaces.  when you give ffmpeg an RGB source and a movie output (`prores_ks`) for example, does it assume going from sRGB to Rec 709?
[21:47:13 CEST] <pa[m]> I would like to render a Prores 4444 movie in RGB without any color conversions, and not in YUV.  As i understand Prores 4444 supports RGB and YUV
[21:51:24 CEST] <kepstin> pa[m]: in most cases when you use the automatic rgb to yuv conversion I think you'll get results equivalent to rec 709
[21:51:30 CEST] <pa[m]> But i'm also curious what the "correct" way is to go from sRGB ~2.2 gamma to Rec 709 2.4
[21:51:46 CEST] <kepstin> in particular, i believe it does *not* do primary conversion, by sRGB and rec 709 use the same primaries
[21:52:01 CEST] <pa[m]> but does it do a gamma conversion?
[21:52:12 CEST] <kepstin> i'm honestly not sure :/
[21:53:02 CEST] <pa[m]> time for some tests then...
[21:53:18 CEST] <kepstin> if you want to be sure about that, it might be best to explicitly do a conversion, possibly using the colorspace or zscale filters.
[21:55:17 CEST] Action: pa[m] sent a long message:  < https://matrix.studiopa.org/_matrix/media/v1/download/matrix.studiopa.org/wttsWkOECpESTdZYDATsFFfA >
[21:55:30 CEST] <pa[m]> seems like `prores_ks` can't write RGB pixels, only YUV
[21:56:01 CEST] <kepstin> that's not unexpected
[21:56:18 CEST] <kepstin> patches welcome, i suppose :)
[21:56:26 CEST] Action: kepstin doesn't know much about prores
[21:57:34 CEST] <pa[m]> cool, just wanted to make sure i wasn't misunderstanding. I am still thankful for free software!
[21:59:52 CEST] <pa[m]> but i suppose you could still just store sRGB in YUV, assuming the YUV->RGB conversion is lossless (pretty sure it is).  Just want to make sure it doesn't do any colorspace conversions; but yes, if it does i can surely force it not to with the colorspace filters...
[22:01:46 CEST] <kepstin> the conversion isn't completely lossless, you have to account for the levels (full range vs. tv range) and rounding/precision issues.
[22:02:29 CEST] <pa[m]> is it possible to pipe custom color primaries or transfer functions into the colorspace filter, or can you only use the presets
[22:02:59 CEST] <kepstin> but yeah, with 4:4:4 encoding you could certainly just throw rgb into the yuv channels and have the encoder encode it as if it was yuv.
[22:03:09 CEST] <pa[m]> specifically curious about P3 colorspace
[22:09:14 CEST] <kepstin> colorspace filter already supports the primaries for P3, listed as smpte431 (DCI) and smpte432 (D65)
[22:11:30 CEST] <kepstin> i dunno what you're supposed to use for color transfer. apparently apple uses srgb for "display p3" and the studio stuff uses gamma 2.6 which that filter doesn't seem to support.
[22:11:40 CEST] <kebabas> kepstin: do you encoded with apple pro ress? i have few questions
[22:12:16 CEST] <pa[m]> yeah i think "display p3" is 2.2 gamma?
[22:12:35 CEST] <pa[m]> and AFAIK P3 D65 is usually used with 2.2 gamma since it's for computer monitors
[22:12:37 CEST] <pa[m]> but i may be mistaken
[22:12:56 CEST] <kepstin> well, sRGB isn't quite the same thing as 2.2 gamma
[22:18:45 CEST] <pa[m]> so for sRGB->Rec 709
[22:18:49 CEST] <pa[m]> `-vf "colorspace=iprimaries=bt709:itrc=srgb:ispace=bt709:primaries=bt709:trc=bt709:space=bt709"`
[22:18:51 CEST] <pa[m]> does that looks sensible
[22:20:02 CEST] <pa[m]> i am not quite clear on what "color space" means here (in compositing software i am used to only dealing with primaries and transfer)
[22:20:07 CEST] <kepstin> pa[m]: yeah, that should basically *just* do the gamma conversion from sRGB to rec 709
[22:20:21 CEST] <kepstin> so, "space" is actually a sort of "preset all" option
[22:20:39 CEST] <pa[m]> i tried this without "space" and it yelled at me
[22:29:03 CEST] <kepstin> hmm. so as far as I can tell, "space" here refers to the coefficients used when doing rgb to yuv conversion
[22:30:45 CEST] <pa[m]> guess i need to do some research then, cause i have no idea what that means
[22:33:08 CEST] <kepstin> in this case i'm pretty sure bt709 is correct - unless, as we found out with a different person who came in here yesterday, the video was a screencap made with shadowplay - in which case you'd use bt601 as ispace ;)
[22:39:26 CEST] <pa[m]> so if i did something like this `colorspace=iprimaries=bt709:itrc=srgb:ispace=bt709:primaries=bt709:trc=srgb:space=bt709`
[22:39:35 CEST] <pa[m]> would that force ffmpeg to not do any color conversions
[22:39:49 CEST] <pa[m]> that might be implicit when you give it rgb and expect a video
[22:39:53 CEST] <SoMuchForSubtlet> Hi, I have a input with multiple audio and video tracks. I want to stream the bese video track and the english audio track to a RTMP server, whats the best way to do this?
[22:40:05 CEST] <SoMuchForSubtlet> *best video
[22:40:13 CEST] <kepstin> pa[m]: that would do nothing, but it would mark the output video with the desired color space properties i guess.
[22:40:29 CEST] <kepstin> SoMuchForSubtlet: how do you know which one is the "best"?
[22:40:54 CEST] <SoMuchForSubtlet> the one it picks by default, highest bitrate and resolution
[22:41:35 CEST] <kepstin> SoMuchForSubtlet: what does ffmpeg print when you run "ffmpeg -i <your input>" ? (please pastebin the results)
[22:42:20 CEST] <SoMuchForSubtlet> here is the ffprobe https://pastebin.com/CgqwCny3
[22:50:30 CEST] <kepstin> alright, so you could probably get away with `-map a:m:language:eng` to select an english audio track (they all seem the  same). I really don't know a generic way to select the best video stream in this case. If they're consistent in the number of programs and program ids they use, you could use `-map p:6:v` to statically select the one from program 6 :/
[22:51:46 CEST] <pa[m]> anyone know what the `colorspace` equivalent of `-vf scale=out_color_matrix=bt709` would be?  because `-vf "colorspace=iprimaries=bt709:itrc=srgb:ispace=bt709:primaries=bt709:trc=bt709:space=bt709"` gives a different result
[22:52:16 CEST] <kepstin> pa[m]: it probably depends on the input video
[22:52:40 CEST] <pa[m]> input is an RGB PNG sequence
[22:52:46 CEST] <SoMuchForSubtlet> kepstin yea I used that to get the audio track, I was also stuck on how to get the right video. Sadly the number of video tracks vary
[22:53:26 CEST] <pa[m]> so perhaps it does not interpret the PNG sequence to be sRGB, maybe it is using 2.2 gamma or something and not the special sRGB transfer function
[22:53:30 CEST] <kepstin> SoMuchForSubtlet: you might have to just check the input (e.g. with ffprobe) and then build a matching ffmpeg command line then :/
[22:53:37 CEST] <SoMuchForSubtlet> the only solution I can think of is to write a script to parse the source m3u8 file and get the video track number that way
[22:56:37 CEST] <kepstin> i'd use ffprobe to avoid the m3u8 parsing, it can dump in a few different formats including json which is kinda nice.
[22:57:22 CEST] <SoMuchForSubtlet> kepstin: maybe I could select one audio track and all video tracks with one ffmpeg command and pipe that into a second ffmpeg command that will select the right video track?
[22:57:59 CEST] <kepstin> SoMuchForSubtlet: still wouldn't help, how would the second ffmpeg command be able to know which video track to select?
[22:58:43 CEST] <SoMuchForSubtlet> it selects the best by default when no map is given
[23:00:04 CEST] <kepstin> hmm? no, it selects the first, not the best.
[23:00:25 CEST] <kepstin> unless there's some weird interaction with "Programs" that i'm not familiar with
[23:02:20 CEST] <SoMuchForSubtlet> no, when I streamed without a map set it picked the 1080p video feed and the first audio track. the 1080p feed is not the first according toffprobe
[23:03:43 CEST] <kepstin> SoMuchForSubtlet: huh. what does it do if you use just "-map 0:v:0" ?
[23:04:23 CEST] <SoMuchForSubtlet> let me try
[23:07:19 CEST] <SoMuchForSubtlet> https://pastebin.com/raw/D2xQKVQ8
[23:07:28 CEST] <SoMuchForSubtlet> and it's only streaming audio it seems
[23:07:53 CEST] <SoMuchForSubtlet> https://player.angelthump.com/?channel=somuchforsubtlety this is the live feed
[23:08:16 CEST] <SoMuchForSubtlet> didnt even pick the right audio haha
[23:09:16 CEST] <qacky> paste shows both audio and video
[23:10:11 CEST] <SoMuchForSubtlet> yea but it looks like only auio is arriving
[23:12:19 CEST] <SoMuchForSubtlet> it picked the first audio feed, not the english one
[23:12:24 CEST] <SoMuchForSubtlet> and the worst video feed
[23:13:31 CEST] <pa[m]> sigh.... i can't reproduce the sRGB->Rec709 that is done natively in After Effects (using ICC profiles/color management) or using Blackmagic Fusion (using the Gamut node) in FFMPEG
[23:13:36 CEST] <SoMuchForSubtlet> this is the output without any maps https://pastebin.com/d6dVCnJB
[23:13:40 CEST] <pa[m]> perhaps it is because ffmpeg wants to be in YUV land
[23:14:45 CEST] <SoMuchForSubtlet> ah, I didnt get video because I didnt set a video codec
[23:14:51 CEST] <SoMuchForSubtlet> still not the right tracks tho
[23:17:17 CEST] <kepstin> SoMuchForSubtlet: yeah, you might just have to script it then :/
[23:17:40 CEST] <kepstin> SoMuchForSubtlet: ffprobe the input, use your own logic to pick the tracks, then run ffmpeg with specific options
[23:18:19 CEST] <SoMuchForSubtlet> yea I'll do that, thanks for the help :)
[00:00:00 CEST] --- Tue Jun 18 2019