Closed madsciencetist closed 1 year ago
Oops, this isn't actually working yet.
Have you tested this with the ffmpeg CLI tool? This will not work as expected because the output frame will not have the correct dimensions. ff_get_buffer uses the sizes specified in AVCodecContext.
ffmpeg -c:v h264_nvmpi -resize:v 1920x1080 -i 235_short.mkv -c: h264 235_t.mkv Input #0, matroska,webm, from '235_short.mkv': Metadata: title : Media Presentation ENCODER : Lavf60.3.100 Duration: 00:01:07.20, start: 0.000000, bitrate: 14175 kb/s Stream #0:0: Video: h264 (Main), yuvj420p(pc, bt709, progressive), 3840x2160, 18 fps, 18 tbr, 1k tbn, 36 tbc (default) Output #0, matroska, to '235_t.mkv': Metadata: title : Media Presentation encoder : Lavf58.29.100 Stream #0:0: Video: h264 (h264_nvmpi) (H264 / 0x34363248), yuv420p, 3840x2160, q=-1--1, 2000 kb/s, 18 fps, 1k tbn, 18 tbc (default)
I found that issue, and I think I fixed it in the commit I just pushed, but I'm still seeing the following behavior:
width/2+1
, the pixels wrap, ruining the imageI see this both with and without WITH_NVUTILS
defined.
Testable with ffplay -vcodec hevc_nvmpi -resize WIDTHxHEIGHT -i INPUT
I thought I fixed it, but I think I was too hasty... downscaling 3840x2160->1920x1080 looks fine now. upscaling 1920x1080->3840x2160 still not working... any ideas?
....too hasty :( downscaling also doesn't work correctly....
p.s. All changes still in master branch. I decided not to revert them for now.
Fixed. The problem was that the ffmpeg buffer had a different alignment than the frame in video memory. NvBuffer2Raw/NvBufSurface2Raw doesn't seem to be able to properly handle such cases, so I replaced them. This problem could occur even without scaling at non-standard resolutions for which the line data size would be different from the size of the line in memory in the ffmpeg buffer. It's great that we found this issue) @madsciencetist, thank you for your contribution!
Oh, nice job @Keylost! I was way behind, still trying to get NvEglRenderer to work so I could just visualize the dma buffer. I'll test right now.
Testing your code now, I'm getting a segfault...let me see what that's about.
With WITH_NVUTILS
, no segfault.
Without WITH_NVUTILS
, I get a segfault either in NvBufferTransform()
, memcpy(dataDst, dataSrc, copySz)
, or in tegra lib worker threads.
Segfault occurs even without resizing
Fixed. Try latest commit. @madsciencetist
That worked! Thank you!
@Keylost last request - before anybody pulls this, think you could you could clean up master by squashing all these resize commits together? I image others will want to pull in this feature to their forks, so it would be great if there was just a single commit to be cherrypicked.
This mirrors the
-resize
option that the cuvid decoders support. The resize operation happens for free while converting from BlockLinear to PitchLinear.