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

[burek]

[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