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

[burek]

[00:00:20 CET] <cone-203> ffmpeg 03James Almer 07release/4.1:abf36b76de63: avcodec/av1_parser: don't abort parsing the first frame if extradata parsing fails
[00:00:21 CET] <cone-203> ffmpeg 03James Almer 07release/4.1:6972b353b4e0: avcodec/cbs_av1: fix range of values for Mastering Display Color Volume Metadata OBUs
[03:04:05 CET] <giggybyte> gotcha, thanks for the information. i'll take a look at the other suggestions, then
[10:15:39 CET] <thardin> grmbl google
[10:17:50 CET] <thardin> maybe I can give them the hackerspace's address
[10:19:15 CET] <nevcairiel> durandal_1707: i found an issue with your cached bitstream reader, specifically get_bits_le just doesn't work, i have a UtVideo file thats broken due to that, disabling cached reader makes it work. Any thoughts?
[10:21:16 CET] <nevcairiel> (here is a sample file that is affected: https://files.1f0.de/samples/ut-test-t2-umrg.mkv)
[10:25:20 CET] <nevcairiel> As I understand the code, the problem is that get_bits_le in the old code also refills using AV_RL, but the new reader always refills with AV_RB, so it has the bytes in a different order.
[10:29:42 CET] <durandal_1707> nevcairiel: on it
[10:32:49 CET] <kurosu> is there a place where it works? (not being sarcastic, just wondering if it is a specific condition)
[10:32:53 CET] <kurosu> though if durandal_1707 is on it
[10:33:25 CET] <nevcairiel> get_bits_le is extremely rarely used in our code
[10:33:32 CET] <nevcairiel> only in like 2-3 obscure formats, and utvideo
[10:34:03 CET] <nevcairiel> and I dont think it can work right now
[10:34:59 CET] <kurosu> might be a refill problem that is cpu-dependent rather than codec-dependent (ie _le should invoke the _le refill?)
[10:35:04 CET] <kurosu> can't try atm
[10:35:33 CET] <nevcairiel> i dont know if its expected that you can mix get_bits and get_bits_le on the same reader
[10:35:36 CET] <nevcairiel> in the old one you can
[10:35:50 CET] <nevcairiel> in the new one, that might be very problematic if you j ust change the refill
[10:36:04 CET] <nevcairiel> unless you keep track of which method you filled with and then purge and re-fill again if it changes
[10:36:08 CET] <durandal_1707> no code does combination
[10:36:21 CET] <durandal_1707> and should not do it anyway
[14:02:15 CET] <cone-892> ffmpeg 03Jun Zhao 07master:e9c9514ce37c: avformat/avformat.h: Update the comment for AVInputFormat.flags
[15:38:45 CET] <nevcairiel> man why do we not have a multithreaded software scaler, this is really holding up my flow here
[15:45:44 CET] <atomnuker> but we do, just slice the frame yourself and run Nx swscale instances in separate threads
[15:46:00 CET] <nevcairiel> last i tried, that didnt work for shit
[15:46:15 CET] <nevcairiel> admittedly its been a while ago
[15:46:20 CET] <atomnuker> you tried that!?!
[15:46:44 CET] <atomnuker> without caring about potential blocking artifacts?
[15:47:48 CET] <BBB> atomnuker doing a pirouette
[15:48:30 CET] <nevcairiel> back then it just resulted in a lot of nonsense
[15:48:46 CET] <nevcairiel> but maybe it was improved since then, i faintly remember reading something about it
[15:48:51 CET] <nevcairiel> but apparently its still crap then?
[15:50:55 CET] <rcombs> atomnuker: I mean if you frame-threaded it'd be fine
[15:51:33 CET] <nevcairiel> I might be ok with a slight delay in this use-case, but its harder to implement as well
[15:51:51 CET] <nevcairiel> i should probably favor hardware scaling, since its hardware encoding anyway
[15:52:07 CET] <nevcairiel> only that i need to write a d3d11 scaler then, and i was lazy  about that
[15:52:32 CET] <JEEB> libplacebo or so?
[15:52:43 CET] <JEEB> then use shaderc to compile to HLSL
[15:52:45 CET] <JEEB> :V
[15:52:52 CET] <nevcairiel> i'm fine with the fixed function d3d11 scaling
[15:52:55 CET] <JEEB> :)
[15:52:56 CET] <nevcairiel> can also hook up deint then
[15:53:15 CET] <atomnuker> write vulkan import export for d3d11
[16:17:13 CET] <atomnuker> I'm impressed, a 53mb total vp9 beats a 140mb h264+aac for a 640x360 video
[16:17:26 CET] <atomnuker> on youtube
[16:18:21 CET] <atomnuker> oh wow there's an av1 version as well, nevermind, I'll watch that
[17:09:20 CET] <rcombs> nevcairiel: what are you encoding with anyway
[17:09:42 CET] <rcombs> (just curious about hardware pipelines on windows, since they're historically pretty awkward)
[17:09:54 CET] <nevcairiel> d3d11 -> nvenc pipeline works pretty well
[17:10:26 CET] <nevcairiel> but its really the only full hardware pipeline i care to support, qsv d3d11 support is broken
[17:10:28 CET] <rcombs> can't use scale_cuda?
[17:10:44 CET] <nevcairiel> cuda filters are nonfree at this time
[17:10:50 CET] <gnafu> atomnuker: I was watching a video the other day that looked really rough in AV1, so I checked out other versions.  It was even worse in VP9, but nearly unwatchable in H.264.
[17:11:09 CET] <gnafu> Didn't look good in any version, though.
[17:11:11 CET] <rcombs> wait, the filters are nonfree but the encoder isn't?
[17:11:23 CET] <nevcairiel> yes, because of the cuda compiler
[17:12:18 CET] <rcombs> huh
[17:13:32 CET] <nevcairiel> right now i'm trying to figure out if supporting  qsv is generally worth it, the ffmpeg encoder seems to be in a somewhat questionable state
[17:15:28 CET] <rcombs> I dunno your use case but generally intel's stuff is stupidly fast
[17:16:23 CET] <nevcairiel> Yeah that part is fine
[17:16:57 CET] <nevcairiel> but the ffmpeg implementation is so bad, it has no runtime  feature probing at all, the sdk you build with determines hardware support, which is just stupid
[17:19:18 CET] <nevcairiel> i should probably round up a few older intel systems and see if i can figure out some way to make it work on them
[17:19:52 CET] <nevcairiel> after i finished tweaking the nvenc stuff i guess
[17:22:19 CET] <nevcairiel> maybe also figure out how the amd stuff works, although i  dont think i have any hardware for that, so meh
[19:21:12 CET] <lotharkript> durandal_1707: I was told you may know this answer: Should the output of a filtercomplex vs vf behave the same when using fps filter and vsync?
[19:29:06 CET] <BtbN> It's just different cli syntax, the create instances of the exact same filters.
[19:29:10 CET] <BtbN> *they
[19:34:49 CET] <lotharkript> BtbN: we found a difference between -filtercomplex fps=fps=60 -vsync 1 and -vf fps=fps=60 -vsync 1. Looking at the code, it seems there is a path being executed with filtercomplex, but not with vf: see https://github.com/FFmpeg/FFmpeg/blob/master/fftools/ffmpeg.c#L1080
[19:35:07 CET] <BtbN> vsync is a horrible hack iirc, and it wouldn't surprise me
[19:35:41 CET] <lotharkript> because the filter does not change the AVframe duration, the hack is using it for vsync
[19:35:58 CET] <lotharkript> so, should the FPS filter update the AVFrame.duration field?
[19:40:51 CET] <BtbN> Only the timestamps really matter anyway
[21:16:46 CET] <cone-867> ffmpeg 03Carl Eugen Hoyos 07master:1e34014010db: lavc/bmp: Avoid a heap buffer overwrite for 1bpp input.
[22:07:57 CET] <lotharkript> BtbN: I agreed that TimeStamp should matter , but looking at this code: https://github.com/FFmpeg/FFmpeg/blob/master/fftools/ffmpeg.c#L1080 they are using the AVFrame Duration, which is incorrect when we use FPS filter
[00:00:00 CET] --- Wed Mar 27 2019