I have a problem I downloaded the latest beta version of shotcut 23.04.20 and when I want to render a movie with music using nvenc encoder then shotcut renders only the music itself without the image. And when I render the movie using libx264 processor then the movie is together with image and music. On the old version of shotcut v22.12.21 everything works fine. Here I made a video how the problem looks like. - YouTube
You should post some information about the HW/OS of your system.
HW encoding depend on your OS, Graphics card, the drivers for you Graphics card.
There is a lot of changed parts in the 23.04.20 pre-release, so even it worked in 22.12.21, it might not work on your system.
I tested nvenc on windows and Linux, and it works for me.
2 Likes
I think I hit a very similar problem in the latest RC 23.04.20 exporting with h264_nvenc: I’m using the same preset I was using in a previous release but for some reason now all my playback apps I tried are having issues with the output .mp4:
-MPC-HC starts playing correctly from the begining but after 30s or so the frames start freezing. Seeking randomly in the file either doesn’t do anything, gives audio only and black screen or plays for a few frames then freezes again (basically like a very bad connection when watching youtube (but this video is on my SSD and it’s 30mbps bitrate so definitely not a speed issue))
-VLC has 1 minute offset between audio and video: starts playing the video at the exact 1 minute mark but audio from begining (yes, at the end there’s 1 minute of black video with the rest of the audio); seeking randomly works quickly and correctly (but the audio is still 1 min offset)
-Windows media player just shows the first frame of the video but audio works and seeks fine
-when loaded in Shotcut it plays back properly (altough it takes 3-4s to seek to random places)
This is a 28 min project so can’t really pinpoint the issue that easily. 1 min test exports seem to work fine for some reason. I’ll try to do more tests.
I’m using Windows 10 and have an Nvidia gtx970 video card.
Edit: tested again with a 2.5min range and have the same issue (except audio offset in VLC is not 1 minute anymore, I’d say it’s around 40s now)
There’s a bunch of these messages in the export log:
[mov,mp4,m4a,3gp,3g2,mj2 @ 000001dae960ebc0] All samples in data stream index:id [4:5] have zero duration, stream set to be discarded by default. Override using AVStream->discard or -discard for ffmpeg command.
[mov,mp4,m4a,3gp,3g2,mj2 @ 000001dae9c73bc0] All samples in data stream index:id [4:5] have zero duration, stream set to be discarded by default. Override using AVStream->discard or -discard for ffmpeg command.
[mov,mp4,m4a,3gp,3g2,mj2 @ 000001dae9be3dc0] All samples in data stream index:id [4:5] have zero duration, stream set to be discarded by default. Override using AVStream->discard or -discard for ffmpeg command.
Ends with:
[mp4 @ 000001daf4347540] Timestamps are unset in a packet for stream 1. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[mp4 @ 000001daf4347540] Encoder did not produce proper pts, making some up.
[mp4 @ 000001daf4347540] Starting second pass: moving the moov atom to the beginning of the file
[AVIOContext @ 000001daeb470380] Statistics: 586875647 bytes read, 0 seeks
[h264_nvenc @ 000001dafa5a08c0] Nvenc unloaded
[aac @ 000001dafa59bcc0] Qavg: 62412.156
[AVIOContext @ 000001daf3a91780] Statistics: 1173671269 bytes written, 4 seeks, 4481 writeouts
Completed successfully in 00:05:57
This part makes no sense, the output file is 559MB (hmm, pretty close to half 559 MB (586,934,320 bytes)): Statistics: 1173671269 bytes written
Edit2: all of these messages also appear in the cpu x265 encode (which works correctly) so they probably aren’t be the cause of the problem
1 Like
I however still have this problem and it is not the fault of the vlc player. Even when I try to upload such a video to youtube, youtube automatically rejects it. I have windows 10 pro and RTX 2070
I’ve made a very simple project (with color clips and text) that fails to play well in VLC for me, it’s made in 23.04.20 without gpu effects (issue is present also with it enabled). Just use default export preset and check use hardware encoder (make h264_nvenc if multiple are available).
I’ve also loaded this project in older 22.12.21 and exporting via nvenc produces a “good” video for vlc.
test nvenc no gpu eff.mlt (6.6 KB)
Here are 3 result videos for comparison GPU, CPU and GPU exported in older version (wetransfer link ~80MB). The way I test these is just open in VLC and for me, the GPU v23 clip starts with a green image (the one in my project, maybe I should have used another color there) instead of the white on black text.
Side note, in v23 both CPU and GPU exports took about 2 mins, in v22 it was only ~30s gpu, ~50s cpu. Weird for such a simple project.
I was only able to reproduce this using the combination of the supplied example project, H.264, and VLC. Playing the output in Shotcut, Firefox, Windows Media Player, and GoPro Player were all fine. Exporting using hevc_nvenc played fine in VLC. Also, when I exported one of my own projects, it was fine in VLC. The example project exported in 23 seconds for me. Still investigating.
I tested hevc_nvenc and for the original 2 minutes project it worked fine (including vlc), but extending the color clip to ~10min it started doing the same problem with only showing the first frame in VLC (but only in VLC, windows media player and mpc-hc seem to work fine).
Interestingly it seems like the long file is bugging the VLC app to the point it doesn’t accept any inputs and closing via the X button only closes the GUI but vlc.exe is still in the process list and can’t open any other file unless force closed from task manager. I also reset preferences in VLC and reinstalled from scratch just now with the same results.
(apparently hevc is so efficient with this project I can easily attach the file here)
test nvenc from v22 - in v23 gpu HEVC long.zip (419.3 KB)
I do not reproduce that problem with your example clip in VLC 3.0.18 on Windows. I made a different test that is less contrived than this simple color clip project that is super compressible but still somewhat simple computer animation: Big Buck Bunny followed by Caminandes Llamigos on the same track in a 1080p60 video mode resulting in a total duration 13:04. This exported using h264_nvenc plays fine for me in VLC. I am still not convinced there is a problem here outside of a driver or VLC version that may also depend on something else about the system environment.
Can you share this so I can see if it plays back fine on my pc? Maybe this will help separate the issue toward my shotcut export + nvenc hardware.
I just copied one of the nvenc exported files (it’s a bigger file: ~2GB with 40mbps bitrate) to my laptop (which has Windows 11 installed, and a good SSD) and I can see the issue both in VLC and MPC-HC (here the issue is quite bad: no sound at all, seeking just shows the image at that point but playback doesn’t start while in VLC it’s the same frozen image but sound is heard and the playback head is moving).
Sadly I can’t test nvenc export on this laptop, only intel’s quicksync. I’ll do a test run a bit later.
This file is playing with absolutely no issues for me. So this means there’s something very particular about my shotcut export and my hardware.
My system has a RTX 3060 with driver version 516.94. The FFmpeg version upgraded to a major new version, but not the NVIDIA Video Codec SDK it is using, which is based on v8.1. The latest is 12, but each new version requires newer drivers making it less likely to work for some users. SDK version 8.1 requires driver version 390. SDK version 11.1 requires driver version 471. SDK version 12 requires driver version 522. I think upgrading the SDK is a long shot, but it might help if some FFmpeg changes were not well tested on an older SDK.
This was also my driver version. I’ve now updated to latest 531.79 (also checked clean install to delete previous settings) to see what happens: I still have the VLC issue but it seems the export time has gone down to ~30s (down from the 2 min I previously reported).
I’ve tested quicksync hardware encoding on the laptop with the provided project and there’s no issue there. You’re probably right about the sdk.
I will update the NVIDIA Video Codec SDK to version 11 for tonight’s build. Please test it tomorrow.
1 Like
Unfortunately the new build (from here) behaves identical.
I also further simplified the test project to literally black color with a timecode in the middle. The starting point for VLC seems to be at the exact 50;00 second mark both for a 2 minute and 10 minute export. Other players also have various issues with it, MPC-HC seems to be the only one to play the file back correctly.
I also quickly tested this 10 min .mp4 on my work PC (Windows 10 host + VM with ubuntu 20) and I have the exact same issue in VLC (it starts at the 50 second mark) and windows media player and other default video viewers either fail to play it at all or show the first frame of 0:00:00.
v23 nightly nvenc mlt + logs.zip (11.9 KB)
I did reproduce that using your latest project file and the combination of h264_nvenc and VLC only. However, I do not know how to fix that. YouTube still accepts it and shows it OK:
Next version will still likely be released in this state. If h264_nvenc does not work on a particular project and player, re-export using something else. Why would one use h264_nvenc anyways and not x264 or hevc_nvenc? But I could remove the h264_nvenc option.
I am fine with this, it seems it affects very few people. I’d say to even keep the old sdk for backwards compatibility (as there’s no improvement anyway).
I have also noticed this, youtube is fine with it. OP maybe had some other issue?
I’d like to argue against removing it: I usually go with h264_nvenc to do quick/fast encodes where I don’t care about filesize (+ I usually export a separate 1440p copy upscaled specifically for youtube’s vp9 codec).
h264 is quite a bit fast for my old card compared to hevc so if I want speed that is the best option.
Local copies I care about filesize so I just use x265.
i am still trying to understrand the problem, but i think i was having something similiar to this problem.
it doesn’t work right on the vlc, and sometimes would work on media player classic
and youtube would reject the thing.
edit: gonna check the other encoders to check if it works, thanks to this post i khow what could have been the problem.
I am still facing the same problem in 23.5.14 (GTX 1080). There is no problem with henvc, but h264 either freezes on the first frame or doesn’t show anything on the screen at all.
However, GOM Player recognizes 0:35 of a 2:52 length video as the first scene and plays it. The sound also starts at 0:35 and even if it goes past 2:52, it doesn’t recognize that the video is over until the sound ends. + The screen ends at 2:52 because it is recognized as having played from 0:00.
The reason I’m sticking with h264 instead of using henvc is that webtwitter doesn’t allow uploading videos with henvc codec. (When I try to upload henvc, it gets stuck at 99% forever!)