SUSE Linux cards

I’m migrating to a Linux box. I’m running SUSE Linux V14.2. Shotcut is up and running. The on-board graphics “board” is not up to the job. The challenge is picking a card that will work well with Shotcut. Nvidia drivers are proprietary (but available from Nvidia). AMD drivers are open-source.

Recommendations?

I have personally, historically had bad experience with AMD drivers’ support for OpenGL (on Linux) and usually use nvidia.

It’s not so much that I have “religion” about AMD vs Nvidia. I don’t want to get caught up in a tug of war between SUSE and Nvidia. As long as a card gets the job done, I’m happy. The problem is I haven’t a clue as to what will get the job done. I’m working on 1080HD 30FPS video (GoPro equivalent) which, I imagine, isn’t as demanding as some sources.

Guidelines? Recommendations?

Any NVidia card will help; as usual, the more expensive, the better. The 750Ti is nice because it has fast memory and doesn’t cost too much. Whichever card you choose to add, check first that your computer’s power supply can handle it.

Also, with any video card, you can speed up scrubbing by transcoding your original video to DNxHD with a high bitrate, and using that instead of the original file. You can do this by exporting from within Shotcut, or with ffmpeg in a terminal:

ffmpeg -i inputfilename.mp4 -s 1920x1080 -r 30 29.97 -vb 220000k -threads 2 -vcodec dnxhd -acodec copy outputfilename.mov

I came up with an AMD R7 240-based card (4Gb of DDR3 - DDR5 preferred but so it goes) which turned out to be plug and play(!) The cross dissolve issue is resolved. Otherwise, “speed costs money. How fast do you want to go?”. Not wanting to rebuild the machine from the ground up, I’ll stick with this card for now.

The second para is, for me, totally baffling. I do get the basics of the ffmpeg command line at least. [/grin]

Please see my how-to question about making a 100% clean copy with one filter [applied]. I suspect that you’re recommending something that addresses the issue.

EDIT: Corrected typo

Sorry if I was cryptic. To define the terms I used:

“Scrubbing” means dragging the timeline’s playhead through the video file, back and forth, to a specific area. Scrubbing can be jerky if the video card, and the disk access, can’t keep up. That’s what I thought you were having trouble with.

“Transcoding” means converting a video file to a different format. You can change the video endoding (by changing the video codec), change the audio encoding (by changing the audio codec), and change the overall container format (e.g. mov, mp4, avi, etc.). You can also set the level of quality for each codec. If you open Shotcut’s export function, you’ll see a list of output formats (e.g. “DNxHD (atsc_1080p_30”). Choosing this would export your video to a .mov file that’s encoded with the DNxHD video codec; this is the one I was referring to. Generally, scrubbing through a DNxHD-formatted file is smoother and less jittery that it is with some other file types. The standard mp4 or mts files created by most video cameras (and which use the h264 codec) are not very good for editing because one can’t scrub smoothly through them.

Exporting with a “high bitrate” just means creating a high-quality file, the higher the better. The “vb 220000k” means a bitrate of 220,000 bits per second, which will produce essentially lossless quality. In fact, that’s Shotcut’s default value for the DNxHD codec.

The “-acodec copy” command keeps the audio codec unchanged.

The “-threads 2” command is optional.

The end result will be a file that works a little more smoothly during the editing process. I find it easier to use ffmpeg to do the transcoding, rather than to open each file in Shotcut and the export it, but the effect is the same.

Regarding your filter question, yes, that’s a good approach - add all the filters and tweaks to a specific file, then export it to a new file, and use the new file for further editing with other tracks. I’ve used that trick successfully; one just has to export the tweaked file using a high-quality setting.

Hope this helps.

Scrubbing… I finally figured out the meaning of scrubbing. I’ve done it often enough - now I know what it’s called. [/LOL]

OK, mystery solved regarding transcoding. At the moment I have an export going on using DN1080p_2997HD. We’ll see what that does.

The ffmepg command line was easy enough to translate after going back to the choices working inside Shotcut.

Thanks for the translation and the “why do it” explanation.

The transcoding finished. Brought back into Shotcut, and comparing with the original, the copy has lost a great deal of contrast! I tried the contrast filter. It took a lot of tweaking to get things right. Not Good. Any ideas about where the wheels might have fallen off?

ADDED: Related to the above: does Shotcut have a histogram capability?

I imported the file into Resolve and looked at the histograms (RGB). It’s not good. The blacks are gone altogether. About 1/8 of the left side of the histogram is flat. It looks as though the histogram was shifted to the right (or whiter) side. In effect, the range from dark to light is compressed. Tweaking brightness and contrast can’t bring back what’s not there.

OK, that is strange. I just transcoded a test .mov from h264 to dnxhd with ffmpeg and also with Shotcut, and both look identical to the original (I chose Shotcut’s “DNxHD(atsc_1080p_2997”, which defaults to 220Mb/s). Tried it on Xubuntu 16.04 and also Windows 10; results were the same. I’m stumped as to to why your video’s contrast/dynamic range changed.

On the plus side, the dnxhd-transcoded videos were much more ‘scrubbable’, but that doesn’t help much if the process mangles your videos.

I’ll play with this some more. Maybe I made a mistake with a setting. If the problem persists, I’ll post a link to “before and after” footage.

It’s important to note this isn’t based on subjective assumptions but a histogram plot of the images. It’s hard to miss the difference.

I took the original footage and the exported footage (DNxHD (atsc_1080p_2997)) and loaded them into Resolve to get histograms for frames from both files. The samples are all at the same point down to the same frame. Original.zip has a screenshot of the frame and its histogram. Copy.zip has the exported screenshot and histogram for the same point.

The original frame is, as the histogram shows, not all that well exposed (too much contrast). So it goes. The exported frame shows the histogram shifted to the right (white) side enough to turn blacks into dark grays, generally washing out the color.

GPU processing is enabled. This is Shotcut 6.11.02.

EDIT: corrected “exported output” to “exported screenshot”

Definitely a difference; I’ve not encountered anything like that. Got me stumped. Does the same thing happen when you transcode with ffmpeg?

I haven’t checked that yet. The problem seems to be Linux-specific.

I tried
ffmpeg -i inputfilename.mp4 -s 1920x1080 -r 30 29.97 -vb 220000k -threads 2 -vcodec dnxhd -acodec copy outputfilename.mov
but didn’t have much luck. -r 30 29.97 didn’t impress ffmpeg:
"Unable to find a suitable output format for '29.97’
29.97: Invalid argument

-r 29.97 (no 30) didn’t help things:
Unable to find a suitable output format for 'outfile.mov’
outfile: invalid argument

Er… say what? I seem to have missed something.