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

[burek]

[01:32:55 CEST] <t-mullen> My raw video input has frames of variable size. How would I change the input size dynamically? Are video filters relevant here?
[01:35:10 CEST] <cehoyos> That cannot work, where do the frames come from?
[01:36:33 CEST] <t-mullen> They're dumped from an RTCVideoSink. Should I just scale the frames before passing them as input?
[01:37:18 CEST] <cehoyos> I don't see how any application (not necessarily ffmpeg) is supposed to know where one frame ends and the next begins if they are not all the same size.
[01:37:45 CEST] <t-mullen> I don't expect it to know, I wanted to know if there was a way to specify frame size alongside the frame.
[01:38:01 CEST] <cehoyos> If it is one frame, you have no problem
[02:41:23 CEST] <DHE> he's gone, but the raw swscale interface is probably the best bet. if resolutions are in a fixed set of possibilities, keep the contexts around I guess...
[14:41:53 CEST] <shibboleth> some application using ffmpeg for streaming expects rtsp over udp
[14:42:15 CEST] <shibboleth> is there any envvar that will use rtsp over tcp by default?
[14:43:54 CEST] <JEEB> no, you just set the AVOption
[14:44:34 CEST] <JEEB> rtsp_transport is one of udp, tcp, udp_multicast, http
[14:44:40 CEST] <JEEB> default is udp
[14:45:09 CEST] <JEEB> you set that to TCP and  you get rtsp over tcp
[14:45:16 CEST] <shibboleth> yeah, but the application doesn't let me specify rtsp transport
[14:45:40 CEST] <JEEB> that is then a problem in the application rather than in the framework
[14:45:47 CEST] <shibboleth> sure
[14:47:02 CEST] <JEEB> if it's an open source application you can patch it of course. if it's not, then you will have to get the source code they used for FFmpeg (since by LGPL rules they have to give you it to be able to replace it)
[14:47:17 CEST] <JEEB> and replace the copy used by the application :P
[14:47:52 CEST] <JEEB> of course in any case I would recommend making a bug report to the application's vendor
[16:56:04 CEST] <logicWEB> just thought I'd throw this out there, I spent the last few days developing this: https://gist.github.com/logiclrd/287140934c12bed1fd4be75e8624c118
[16:56:11 CEST] <logicWEB> I wanted film grain that wasn't just straight HD pixels
[16:56:25 CEST] <logicWEB> I'm now running an encode and we'll see what it looks like but my previews looked hopeful :-)
[17:00:39 CEST] <logicWEB> the one thing I'm unsure about is aq-strength -- someone on a forum said high aq-strength is great for preserving grain, he said to use 1.8 or 1.9, but -tune grain uses aq-strength 0.5, where the default is 1.0?
[17:00:53 CEST] <durandal_1707> logicWEB: you should avoid use of geq at all costs, it is _bad_
[17:02:04 CEST] <durandal_1707> geq=lum='255-lum(X,Y)':cb=128:cr=128 this can be done much faster with lut filter
[17:02:56 CEST] <logicWEB> bad as in slow or bad as in doesn't actually do what you were expecting?
[17:03:05 CEST] <durandal_1707> geq=red_expr=random(1)*256:green_expr=random(1)*256:blue_expr=random(1)*256 --- this one you could use real noise like /dev/random
[17:03:12 CEST] <durandal_1707> it is very slow
[17:03:49 CEST] <logicWEB> I'm running on Windows so I don't have /dev/random :-P
[17:07:02 CEST] <durandal_1707> logicWEB: you do not like noise filter grain?
[17:07:57 CEST] <logicWEB> is `noise=alls=100:allf=t+u` equivalent to that `geq` thing?
[17:08:29 CEST] <logicWEB> I just changed my command line to that and it is, as expected, much faster that 3 per-pixel general expressions at twice the video resolution :-P
[17:09:08 CEST] <logicWEB> okay I just tested with ffplay, it's not the same
[17:09:13 CEST] <logicWEB> even with alls=100 the noise is very dark
[17:12:41 CEST] <durandal_1707> that is because you are supposed to use it directly on video
[17:15:25 CEST] <furq> logicWEB: also just use c0s and omit hue
[17:18:43 CEST] <durandal_1707> ffmpeg -f lavfi -i color=gray:s=vga,noise=alls=100:allf=t,hue=s=0,deflate=threshold0=15,dilation=threshold0=10,eq=contrast=3,scale=320x240
[17:18:47 CEST] <JEEB> squirrel: /25
[17:18:51 CEST] <JEEB> asdf
[17:19:15 CEST] <durandal_1707> use that if you really need big noise patches
[17:23:26 CEST] <logicWEB> also looks like my `geq=lum='256-lum(X,Y)'` can be done with `negate` instead more quickly
[17:24:03 CEST] <durandal_1707> negate is actually lut filter :-)
[17:36:29 CEST] <logicWEB> just did some tests, I can't actually tell the difference between aq-strength 0.5 and aq-strength 1.9, maybe because the CRF is so high? I guess I'll just go with what -tune grain recommends?
[17:37:11 CEST] <furq> it's doubtful you'll notice the difference between any x264 settings at crf 12
[17:37:31 CEST] <furq> you could probably run ultrafast and not notice
[17:37:47 CEST] <logicWEB> except I'd notice the filesize :-P
[17:38:20 CEST] <furq> you'd be surprised
[17:39:04 CEST] <logicWEB> oh yeah? I mean, I compared veryfast with veryslow and got a file that was twice the size...
[17:39:54 CEST] <logicWEB> also I was reading about it in a little bit of depth a week or two back and read that while the _intent_ is for the speeds to have virtually no effect on the quality in CRF mode, _in practice_ veryslow turns some features on that _in some rare cases_ will find better solutions for things and actually look better
[17:40:09 CEST] <logicWEB> if there's even a tiny effect I'm willing to pay an extra day of CPU time :-P
[17:53:15 CEST] <scottchiefbaker> What is the current status of the native AAC encoder?
[17:53:29 CEST] <JEEB> it's pretty usable for LC-AAC
[17:53:29 CEST] <scottchiefbaker> Is it still sub-par quality compared to the fdk one?
[17:54:17 CEST] <JEEB> there are some specific use cases where it seems to handle some things worse but in general I would have no issues utilizing it given that the binaries can be re-distributed with GPL stuff like x264/5 enabled
[17:54:39 CEST] <scottchiefbaker> JEEB: Ok good.
[17:54:40 CEST] <scottchiefbaker> https://trac.ffmpeg.org/wiki/Encode/AAC#NativeFFmpegAACEncoder
[17:54:57 CEST] <scottchiefbaker> Do you know anything about the VBR stuff? Is the VBR still a work-in-progress?
[17:55:03 CEST] <scottchiefbaker> or should I just stick to CBR
[17:55:20 CEST] <scottchiefbaker> "This VBR is experimental and likely to get even worse results than the CBR."
[17:55:34 CEST] <JEEB> not sure when that line was written or by whom - and I haven't checked myself
[17:55:56 CEST] <JEEB> so can't say anything one way or another
[17:56:11 CEST] <JEEB> (esp. since I generally just set a bit rate like 96-192k)
[17:56:27 CEST] <scottchiefbaker> a range? or a specific bitrate?
[17:57:07 CEST] <JEEB> specific
[17:57:13 CEST] <JEEB> something from that area
[17:57:39 CEST] <JEEB> for local usage I usually go 192k since I don't generally re-encode unless I absolutely have to, and if I have to for local usage I have no real need to skimp on bits
[20:50:52 CEST] <irwiss> i've been looking at https://ffmpeg.org/doxygen/4.1/hw__decode_8c_source.html and it seems to grab the hw device type from the cli args, ffmpeg returns all of cuda, dxva2, qsv, d3d11va "available" on this laptop but afaik intel integrated gpus can't use cuda? trying to open it seems to fail at av_hwdevice_ctx_create, so my question is; what's the s
[20:50:52 CEST] <irwiss> trategy for detecting the correct type to open, a list sorted by priority and just trying until success or fallback to software?
[20:53:01 CEST] <irwiss> also qsv seems to fail as well though it looks like it should work, is my hardware not compatible (Iris 540) or do i need the Intel Media SDK which https://trac.ffmpeg.org/wiki/Hardware/QuickSync warns not to install unless you need it, but i guess that folds into the question; how do i figure out which hw type out of the ones ffmpeg lists to open
[20:53:46 CEST] <JEEB> you as an API or otherwise user should know what you should attempt on a specific piece of hardware. what is available is just what's available in the build of FFmpeg you have around
[20:54:10 CEST] <JEEB> for decoding in Windows you generally want to use either dxva2 or d3d11va in any case
[20:54:11 CEST] <irwiss> ah so "available" is just compile time "flags"
[20:54:22 CEST] <JEEB> yes, they're available in the build
[20:54:34 CEST] <JEEB> so when you attempt them the framework will attempt to utilize them
[20:54:53 CEST] <JEEB> and then fail in case where you don't have the required stuff
[20:55:19 CEST] <JEEB> but yea, on windows it's pretty simple since pretty much everything puts their hardware decoding into the windows APIs
[20:55:27 CEST] <JEEB> thus dxva2 or d3d11va
[20:57:04 CEST] <irwiss> i suppose if on windows i should try d3d11 then dxva2(which seems to be dx9) then fall back to software, can i just try opening them one by one until i succeed? or do i need to destroy the format/codec context
[20:57:48 CEST] <JEEB> avformat context is separate anyways so no real need to close that
[20:58:04 CEST] <JEEB> just keep the AVPackets around to feed the same stuff into the decoder
[20:59:03 CEST] <JEEB> also I think your hw decoding context creation generally fails way before you start feeding it AVPackets I think?
[20:59:20 CEST] <JEEB> (into the AVCodecContext
[20:59:35 CEST] <irwiss> it looks like i'm not feeding packets yet by the time this fails, yep i was just wondering if trying to open hw context changes some internal ffmpeg state on those structures
[21:00:10 CEST] <irwiss> guess i'll try and find out, hopefully it crashes before someone reports it doesn't work on their machine, thanks for the help!
[21:00:11 CEST] <JEEB> avformat instance should be quite separate from the avcodec instance(s) you initiate
[21:00:38 CEST] <JEEB> yea, unfortunately some hardware decoders have been less fun to deal with - but that could happen even without any mistake on your side :)
[21:00:50 CEST] <JEEB> feed some funky bit stream to the hw decoder and receive bacon in the sense of BSoD
[21:01:13 CEST] <JEEB> thankfully lately such drivers or hw decoders on PCs are starting to become more rare
[21:01:17 CEST] <irwiss> yeah i'll try restarting just the codecs first, the startup sequence seems to be blazing fast
[21:01:35 CEST] <irwiss> and fingers crossed no driver bugs with bsods :D
[21:03:37 CEST] <JEEB> in mpv I think after X amount of failures with hwdec we fall back and create a swdec instance
[21:04:20 CEST] <JEEB> also I've found that hwdecs are much more likely to bail out with a broken/unsupported bit stream
[21:04:37 CEST] <JEEB> the FFmpeg swdec is trying quite hard :)
[21:07:22 CEST] <JEEB> also the biggest difference between d3d11va and dxva2 seem to be indeed the newer/older back-end on the D3D side. which also means that with dxva2 you can get native D3D9 GPU surfaces, and with d3d11va you can get native GPU D3D11 surfaces
[21:17:10 CEST] <irwiss> yeah my follow up task is trying to figure out if i can somehow supply my own d3d11 surface into the decoder, even with hw decoding but then juggling the buffers through system ram appears to be too slow for 4k videos on this laptop though vlc and mpv run the video just fine and so it looks like the roundtrip through system ram kills performance, s
[21:17:10 CEST] <irwiss> earching the intertubes provides very little info on the subject but ffmpeg apis in the docs look promising
[21:28:54 CEST] <__raven__> hi
[21:30:08 CEST] <__raven__> processing images to video clips sometimes leads to an endless loop caused by "invalid data found..." due to negative duration. how to exit that?
[00:00:00 CEST] --- Sat Apr 20 2019