[00:19:17 CET] <BtbN> kepstin, yes, it seems like the vast majority of my issues just went away by pulling a more recent version with that patch in. [14:28:38 CET] <bencc1> kepstin: I've added "-af aresample=async=1" and now I'm not getting "Queue input is backward in time" warnings in the log [16:14:08 CET] <barhom> Is cuvid (legacy) deprecated over cuda hwaccel for decoding? Are the plans to remove cuvid in the future? [17:01:10 CET] <kepstin> barhom: my impression is that the nvdec/nvenc stuff is the current recommendation [17:01:46 CET] <barhom> kepstin: i.e. cuda? [17:02:19 CET] <barhom> been trying to google the difference between cuvid and cuda but I cant find any good information on the subject [17:02:20 CET] <kepstin> i didn't say cuda, i said nvdec [17:02:39 CET] <barhom> kepstin: The question was related to "-hwaccel cuda" [17:02:54 CET] <barhom> "nvdec" is an alias of cuda afaik [17:03:33 CET] <barhom> as such I think cuda should be the right name, there are no reference to "nvdec" in "ffmpeg -hwaccels" [17:04:02 CET] <kepstin> ... what ffmpeg version do you have? [17:04:16 CET] <barhom> git-2019-12-27 [17:04:55 CET] <kepstin> weird, i wonder if it was compiled with nvdec disabled somehow [17:05:27 CET] <barhom> I can still use "-hwaccel nvdec" but its the same as "cuda" [17:05:45 CET] <barhom> Hardware acceleration methods: cuda, cuvid are the only two options [17:06:13 CET] <kepstin> oh, huh, i didn't realize that it was named cuda [17:06:29 CET] <kepstin> it's weird because all of the actual source code files are named "nvdec" :/ [17:06:53 CET] <barhom> Anyways, the question is if cuda/nvdec (same thing) is the preferred option over cuvid. From what I understand from what I have read it is. And someone mentioned that cuvid is deprecated but I cant find any source to that. [17:07:16 CET] <barhom> If someone do have a nvidia card I would love if you can try what I have written here and see if you get the same results as me: https://trac.ffmpeg.org/ticket/8442 [17:09:17 CET] <kepstin> barhom: can you reproduce only using the hardware decoder, with a software encoder? [17:09:42 CET] <barhom> kepstin: the encoder doesnt matter you can use h264_nvenc or libx264 [17:09:58 CET] <barhom> what makes or breaks it is the decoder (cuda vs cuvid) [17:10:36 CET] <kepstin> barhom: it would be good to note that in your ticket, since it's possible it could have been an interaction between the hardware decoder and encoder [17:11:50 CET] <barhom> Yeh, I'll mention it. [17:11:58 CET] <kepstin> hmm, my only pascal card with nvdec isn't in a working computer right now :/ [17:12:13 CET] <barhom> The only difference between the two commands are the decoding (before the -i) [17:17:13 CET] <kepstin> just to note that if i do try to reproduce this, my 1030 gt only has nvdec, it does not have nvenc, so I cannot test with a full hardware pipeline. and it's possible that there's a difference. [17:46:22 CET] <bencc1> kepstin:"-af aresample=async=1" 'm not getting "Queue input is backward in time" warnings in the log [17:46:34 CET] <bencc1> and there is no noticable effect on audio [17:47:14 CET] <bencc1> I've listened to mp4 before and after and I can't distinguish. no gaps or pitch issues [17:47:16 CET] <bencc1> is it safe to use? [17:48:05 CET] <bencc1> someone also suggested using "-af asetpts=N/SR/TB" [17:54:10 CET] <kepstin> i would have expected the aresample thing to cause a pitch change, since in theory it should be stretching the audio out to match the packet timestamps [17:54:31 CET] <kepstin> the asetpts would probably cause desync, but feel free to try it [17:55:50 CET] <bencc1> kepstin: maybe the pitch difference is unnoticeable because aresample is streching at most part of a sample [17:56:11 CET] <bencc1> is there audio file that I can test with that will enhance the pitch difference? [00:00:00 CET] --- Sat Dec 28 2019