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

[burek]

[01:50:41 CEST] <lemontea> hey guys
[01:53:51 CEST] <lemontea> Just working on a decklink device and wondering if it is available to set modes above the format_code "4d25", or 8K resolutions, I only have found a list of these formats of up to 4096x2160 at 25hz.  Anyone know?
[11:56:22 CEST] <yong> I have a question about CRF encoding. My expectation would be that when using, as an example, CRF 20 with libx264, the output should always look close to the same no matter the preset, and that a lower preset would result in a lower file size. I made a 47-second test video recorded losslessly with nvenc. Then I encoded that video with ffmpeg, once for medium, fast, faster and veryfast. The file sizes for medium, fast and faster are very close,
[11:56:23 CEST] <yong> and the file size for veryfast is significantly smaller than the rest.
[11:56:28 CEST] <yong> How does that make any sense?
[11:56:45 CEST] <yong> I would've expected the file size to gradually increase when using a faster preset
[11:58:31 CEST] <BtbN> faster presets turn of features, so you might end up with worse quality as well
[12:03:31 CEST] <yong> Hmm interesting, that seems to be a pretty common misconception about how CRF works then
[12:05:34 CEST] <JEEB> yes
[12:05:43 CEST] <JEEB> people expect it to always be the same quality, which it is not
[12:05:50 CEST] <JEEB> it is a rate factor, after all
[12:06:04 CEST] <JEEB> also affected by the analysation parameters
[12:06:20 CEST] <JEEB> I've myself gotten scolded by pengvado circa 2010 for calling it constant quality
[12:06:24 CEST] <JEEB> :P
[12:07:09 CEST] <JEEB> one of the most obvious cases is when you go to the most slowest presets, when you go slower you might actually gain file size
[12:07:14 CEST] <JEEB> because the encoder "sees more"
[12:08:04 CEST] <yong> Unfortunately that also means that there's no easy way to "compression efficiency" against encoding speed then :/
[12:08:52 CEST] <JEEB> you can as long as you don't define the parameter as quality
[12:09:06 CEST] <JEEB> check awcy (are we compressed yet)
[12:09:24 CEST] <JEEB> basically acknowledge that metrics are not visual quality
[12:09:52 CEST] <JEEB> but that we have metrics, using multiple of which can help determine some sort of "efficiency factor" to compare things against each other
[12:16:54 CEST] <Mavrik> Should just add a "--make-it-look-pretty" flag to ffmpeg to avoid all of these confusing terms ;)
[12:21:44 CEST] <yong> Anyway, different question. I encode with "ffmpeg -i test.mov -an -c:v libx264 -crf 20 -preset medium test-medium.mov" - the source file has this video stream
[12:21:47 CEST] <yong> Stream #0:0(eng): Video: h264 (High 4:4:4 Predictive) (avc1 / 0x31637661), yuv420p(tv, bt709/unknown/unknown), 1920x1080 [SAR 1:1 DAR 16:9], 227356 kb/s, 60 fps, 60 tbr, 15360 tbn, 120 tbc (default)
[12:22:04 CEST] <yong> But the resulting file has this as video stream
[12:22:04 CEST] <yong> Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 9545 kb/s, 60 fps, 60 tbr, 15360 tbn, 120 tbc (default)
[12:22:47 CEST] <yong> Why did it change from 709 to what I can only assume is 601 color space? Do I have to specify that?
[12:35:09 CEST] <yong> I guess I have to since -colorspace bt709 works, seems a bit weird to me but oh well
[12:36:32 CEST] <JEEB> I guess ffmpeg.c does not initialize the encoder with the data. I've actually tried to make the libx264 wrapper update the colorimetry according to the AVFrames
[12:36:38 CEST] <JEEB> but I couldn't get it working :P
[12:37:01 CEST] <JEEB> also how old is your version, I'm pretty sure that worked in some cases
[12:57:34 CEST] <yagiza> Hello!
[12:58:16 CEST] <yagiza> How can I specify output format for muxing/encoding when using custom I/O?
[12:59:11 CEST] <yagiza> Output PROTOCOL, not FORMAT.
[12:59:37 CEST] <yagiza> I try to encode SRTP stream, but there is no such output format as "SRTP", only protocol.
[13:00:25 CEST] <yagiza> Whe no custom I/O used, output format is decided according to target URL scheme.
[13:01:31 CEST] <yagiza> But when custom I/O is used, output filename is ignored, so I don't know a way to tell FFMpeg to encode SRTP stream instead of RTP one.
[13:26:39 CEST] <yong> JEEB: Newest version from zeranoe (N-91972-gbd10c1e9a8). It might work in other configurations, considering how many different stream/container formats there are. I'm also not entirely sure if the color space gets actually transformed or if the tag just doesn't get propagated.
[14:28:22 CEST] <Yagiza> Do any1 know what to do with RTCP packets generated by RTP muxer and what to do with RTCP packets, generated by RTP demuxer?
[14:29:25 CEST] <Yagiza> Right now I feed them all to RTP demuxer on another side along with RTP packets. But I'm not sure that this behavior is correct.
[15:58:22 CEST] <saml> what does ffmpeg mean? fast fourier media processing effects gnu?
[16:00:27 CEST] <durandal_1707> exactly that
[19:08:50 CEST] <GuiToris> hello, can ffmpeg do something about the wobbly jello effect caused by the cmos camera's rolling shutter sensor
[21:26:18 CEST] <mozzarella> can I encode a video using hardware acceleration?
[21:26:35 CEST] <nicolas17> depends on the codec and the hardware and the drivers and what quality you're expecting
[21:26:53 CEST] <ntd> if your ffmpeg is compiled and etc etc...^
[21:27:11 CEST] <mozzarella> is there a quick way to check if I can
[21:27:57 CEST] <nicolas17> the quick way is answering what codec you want and what hardware you have
[21:28:39 CEST] <mozzarella> the codec is x264, right? that's a codec right?
[21:28:56 CEST] <furq> it is a codec but it's also not hardware accelerated
[21:28:58 CEST] <JEEB> it's an encoder that encodes in the H.264/AVC format
[21:29:18 CEST] <JEEB> also an encoding chain consists of everything from decoding to filtering to encoding :P
[21:29:26 CEST] <JEEB> which part are you interested in accelerating :P
[21:29:44 CEST] <mozzarella> what is filtering?
[21:29:46 CEST] <nicolas17> h264 is a format, x264 is a *software* encoder for it, you can use other encoders that use hardware (and probably give worse results)
[21:30:02 CEST] <JEEB> mozzarella: deinterlacing, scaling, colorspace conversions etc
[21:30:04 CEST] <furq> s/probably//
[21:30:50 CEST] <mozzarella> nicolas17: why would they give worse results?
[21:31:04 CEST] <mozzarella> I want to use hardware encoding because I think it's going to be a lot faster
[21:31:09 CEST] <nicolas17> it's going to be faster
[21:31:14 CEST] <JEEB> (maybe)
[21:31:14 CEST] <nicolas17> it's going to take more space or look worse
[21:31:24 CEST] <JEEB> I mean, x264 preset ultra/superfast is pretty darn fast :P
[21:31:42 CEST] <mozzarella> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series]
[21:31:43 CEST] <nicolas17> x264 can be improved with a software upgrade, your GPU chip with hard-wired encoding logic can't
[21:31:44 CEST] <JEEB> but yes, compression wise those are made for low latency and just not using the CPU
[21:31:57 CEST] <kepstin> mozzarella: if you need to use the cpu for something else, then using a hardware encoder can make sense.
[21:32:25 CEST] <mozzarella> JEEB: which preset am I using by default?
[21:32:34 CEST] <JEEB> medium in x2645
[21:32:48 CEST] <kepstin> mozzarella: also note that the radeon hardware encoder isn't as good as some other brands, and that's a pretty old card. I wouldn't expect great results there.
[21:33:07 CEST] <jkqxz> That card doesn't contain any hardware encoding capability at all.
[21:33:31 CEST] <mozzarella> JEEB: https://i.imgur.com/oZspwZk.png
[21:34:16 CEST] <mozzarella> I'm pretty sure handbrake is using ffmpeg behind the scene
[21:34:19 CEST] <furq> that's an ominous image
[21:34:26 CEST] <jkqxz> It has some decode and processing if you want to use it for other parts, but generally encoding is the largest time component anyway so the gain is unlikely to be anything but marginal.
[21:34:51 CEST] <nicolas17> jkqxz: no programmable GPGPU that can be (ab)used for encoding either?
[21:35:07 CEST] <JEEB> video encoding doesn't work with that
[21:35:08 CEST] <jkqxz> GPUs are completely hopeless at encoding.
[21:35:09 CEST] <mozzarella> furq: ominous how? because of the blue tint?
[21:35:09 CEST] <JEEB> like seriously
[21:35:15 CEST] <furq> no the preview image
[21:35:17 CEST] <JEEB> people tried that 2006-2008
[21:35:22 CEST] <JEEB> so much kool-aid was had
[21:35:23 CEST] <nicolas17> jkqxz: ah ok
[21:35:31 CEST] <JEEB> and then they learned and that is why we have the ASICs on the cards now :P
[21:35:52 CEST] <JEEB> because even those selling the GPGPGPGPU solutions now have ASICs
[21:36:16 CEST] <furq> x264 can use opencl for lookahead
[21:36:25 CEST] <furq> but it doesn't work well enough to bother using
[21:36:27 CEST] <mozzarella> furq: that's me sleeping
[21:36:34 CEST] <mozzarella> the original file is too big
[21:36:41 CEST] <jkqxz> Given an intra-only codec with no interdependency they can be used, but anything even slightly recent for sensible bitrates has so much interdependency between parts that it's not useful.
[21:36:44 CEST] <mozzarella> I want to shrink it down by reencoding
[21:36:59 CEST] <JEEB> yea, ATi actually made their own format for GPGPU encoding
[21:37:03 CEST] <JEEB> but that was *not* for compression ratios
[21:37:11 CEST] <JEEB> it was just for the "run this on hundreds of threads pl0x"
[21:37:19 CEST] <JEEB> so it could run somewhat OK on a GPU
[21:37:27 CEST] <nicolas17> will hardware encoding save enough time compared to x264 if you also take into account the time spent discussing here?
[21:37:57 CEST] <mozzarella> dunno?
[21:38:13 CEST] <TheAMM> nvenc is blazing fast for me and I never discussed it here so I don't know my sins
[21:38:20 CEST] <TheAMM> and happy for it
[21:38:22 CEST] <mozzarella> what's my best chance of getting it faster? choosing another preset?
[21:38:29 CEST] <JEEB> TheAMM: that at least can do lossless
[21:38:42 CEST] <JEEB> which is why I have 2160p video capture of one of the alchemist games
[21:38:57 CEST] <JEEB> (lossless at 4:4:4, mind you)
[21:38:57 CEST] <TheAMM> I wish I could do 444 or something but my card doesn't support that??
[21:39:10 CEST] <TheAMM> At least OBS fucks up colors when I record desktop
[21:39:18 CEST] <TheAMM> In games I don't really notice or mind
[21:39:30 CEST] <TheAMM> but text being bad is bad
[21:39:47 CEST] <JEEB> yea
[21:39:53 CEST] <JEEB> funny enough it can't hwdec what it produced
[21:39:58 CEST] <JEEB> but hey, at least you get 4:4:4 \o&
[21:40:35 CEST] <JEEB> (and lossless capture is something where the GPU encoder can be quite handy)
[21:41:13 CEST] <mozzarella> I don't know what 4:4:4 is
[21:41:20 CEST] <JEEB> full chroma
[21:41:23 CEST] <JEEB> most video is 4:2:0
[21:41:37 CEST] <JEEB> which is full resolution for the "black and white" (brightness)
[21:41:40 CEST] <JEEB> aka luma
[21:41:50 CEST] <JEEB> and one sample for 2x2 block for chroma (colors)
[21:48:43 CEST] <mozzarella> so how do I encode faster
[21:48:49 CEST] <nicolas17> faster CPU
[21:53:14 CEST] <satoshi2> download more cpu cores
[22:03:47 CEST] <iive> mozzarella, use the "faster" preset
[22:04:18 CEST] <mozzarella> iive: is the quality going to be the same?
[22:04:37 CEST] <iive> are you using crf ?
[22:04:44 CEST] <nicolas17> depending on other paramters, either quality or file size are going to suffer
[22:05:20 CEST] <iive> with same crf going from faster to veryslow makes the file 5% smaller.
[22:05:45 CEST] <mozzarella> what is crf?
[22:06:04 CEST] <iive> faster has mbtree and trellis and they are important for good encoding.
[22:06:20 CEST] <iive> constant rate factor....
[22:07:00 CEST] <nicolas17> this is #ffmpeg, we're going to give ffmpeg options, if everything is abstracted by your GUI (handbrake) maybe you should try asking for help in a handbrake channel :P
[22:07:29 CEST] <iive> i'm sure handbrake does have crf option.
[22:07:33 CEST] <iive> it used to.
[22:08:07 CEST] <nicolas17> probably
[22:08:12 CEST] <nicolas17> as long as he doesn't expect us to know where it is :)
[22:08:25 CEST] <Something1> Handbrake does have a crf option yes
[22:09:53 CEST] <iive> crf and qp set the data loss, the bigger the number, the worse quality you get.
[22:12:30 CEST] <iive> 18 should top quality. for tv shows i watch and delete i use 24
[22:14:10 CEST] <Something1> I am a huge fan of reducing the qcomp to reduce size instead of upping the crf
[22:16:21 CEST] <mozzarella> is x265 fast at encoding?
[22:16:27 CEST] <JEEB> pfffft
[22:17:49 CEST] <nicolas17> mozzarella: it's going to be obviously slower than x264 :)
[22:17:59 CEST] <mozzarella> nicolas17: why?
[22:18:32 CEST] <JEEB> HEVC compared to AVC has more features and same features got more options
[22:18:38 CEST] <JEEB> now the encoder has even more things to decide on
[22:23:08 CEST] <nicolas17> you want better quality, less file size, and taking less time? here, have a lollipop
[22:24:06 CEST] <Something1> nicolas17, that´s basically x264 compared to anything before though
[22:24:24 CEST] <JEEB> uhh
[22:24:30 CEST] <JEEB> sir let me take you to 2006
[22:24:45 CEST] <JEEB> I mean, x264 is ridiculously fast with modern hardware
[22:24:52 CEST] <JEEB> but it definitely was slower than xvid
[22:24:59 CEST] <JEEB> or I think libmpeg2?
[22:25:19 CEST] <nicolas17> it wouldn't surprise me if multi-threaded x264 is faster than single-threaded libmpeg2 ;)
[22:26:02 CEST] <JEEB> of course the problem with xvid or lavc's mpeg4 (part 2) encoder was that they'd start falling apart at rates where x264 could handle things JustFine
[22:26:23 CEST] <Something1> Hmm I was specifically thinking of the current x264 compared to anything but h265 codecs. I might well be wrong though.
[22:26:25 CEST] <JEEB> too bad x265 never got the nerd boost
[22:26:38 CEST] Action: JEEB tried to contribute for a while
[22:26:51 CEST] <JEEB> but it was clearly MCW doing their thing
[22:26:53 CEST] <Something1> h265 has near zero adaptation, while h264 is everywhere. I still use x264 for everything
[22:27:08 CEST] <nicolas17> Something1: did you try MPEG2 or MPEG4 ASP encoding in modern hardware recently?
[22:27:25 CEST] <JEEB> HEVC was a good format but it got 100% killed by the companies wanting more money (for licensing)
[22:27:43 CEST] <JEEB> and x265 due to all that then ended up a one-?an corporate show
[22:28:06 CEST] <Something1> nicolas17, no.. is that so much faster? Sorry, then I am off
[22:44:05 CEST] <mozzarella> woooooo, encoding done
[22:46:51 CEST] <mozzarella> well shit, the quality dropped
[22:50:51 CEST] <mozzarella> if I choose the preset "very fast 720p30" instead of "very fast 1080p30", is it going to make a difference? my video is 720p originally
[22:51:38 CEST] <Something1> @mozzarella please try to find support for Handbrake specifically to get better responses.
[22:52:02 CEST] <mozzarella> I don't think they have an irc channel
[22:52:10 CEST] <nicolas17> mozzarella: if your original is 720p you're wasting time by upscaling it to 1080p
[22:52:26 CEST] <Something1> https://handbrake.fr/community.php I would think otherwise
[22:52:31 CEST] <mozzarella> nicolas17: thing is, the resulting file isn't even 1080p, it's still 720p
[22:52:41 CEST] <mozzarella> despite the preset being 1080p
[22:52:51 CEST] <nicolas17> then I have no idea what that preset even does and it turns into a handbrake question
[22:54:14 CEST] <Something1> Handbrake does not alter the resolution of the output file based on presets, so indeed.. handbrake support is completely different to ffmpeg support
[22:55:50 CEST] <mozzarella> I'm getting 151 fps with preset Very Fast
[22:56:51 CEST] <mozzarella> there's no one in #handbrake
[22:56:57 CEST] <mozzarella> and I like you guys a lot more
[22:57:29 CEST] <Something1> Perhaps try the forums or the documentation.
[22:58:02 CEST] <mozzarella> I think I'm just going to try both and see if there's a difference
[23:53:14 CEST] <poutine> I have been using libcaption for embedding captions in the SEI NALU of h264 video for some time. It only works with FLVs for some reason, and I'm trying to mux captions to existing rendition mpeg-ts segments. I can easily figure out which captions go with which segment, and mux them if I switched the container to FLV, but I lose PTS/DTS values in the container switch, is there some way I can restamp it as it was before the container shift?
[23:55:17 CEST] <poutine> it's like ffmpeg -i input.ts -c copy -f flv - |flv+srt foo.srt - |ffmpeg -i - -c copy -f mpegts out.ts
[23:56:27 CEST] <JEEB> I would recommend either building your own API client or seeing if you can integrate caption loading from an input in some format
[23:56:42 CEST] <JEEB> *integrate into ffmpeg.c
[23:56:56 CEST] <JEEB> I just don't know what the intermediate formats would usually be for captions :P
[23:57:26 CEST] <JEEB> or if you take in something like SRT, then probably you need a closed caption encoder (we already have a decoder)
[23:57:41 CEST] <poutine> yeah no cc608 encoder yet as far as I could tell
[23:58:12 CEST] <JEEB> then the "special" part is that closed caption packets are then attached to video stream AVFrames/AVPackets as side data
[23:58:37 CEST] <JEEB> so your input would be a separate stream, but your output would be merged to a video stream or streams
[23:59:49 CEST] <JEEB> due to how shitty dynamic subtitle support is in web streaming (stuff like "you can't add/remove streams from a HLS master playlist")
[00:00:00 CEST] --- Wed Sep 19 2018