VDPAU Playback Issue (Problem Solved).

One of the facts which apply to Linux computing is, that NVIDIA created an API, which allows for certain video-streams to be played back in a way accelerated by the GPU, instead of all the video decoding taking place on the CPU. And, users don’t necessarily need to have an NVIDIA graphics card, in order for certain graphics drivers to offer this feature, which is called ‘VDPAU’, an acronym that stands for “Video Decode and Playback API for Unix”. Simultaneously, what some Linux users can do, is to experiment with shell-scripts that allow us to click on a specific Application Window, in order to perform screen-capture on that Window for a specified number of seconds, ad then to compress the resulting stream into MP4, AVI, or MPG -Files, once the screen-capture has finished. This latter piece of magic can be performed using elaborate ‘ffmpeg’ commands, which would need to be a part of the script in question. And in recent days, I’ve been tweaking such scripts.

But then an odd behaviour crept up. My NVIDIA graphics card supports the real-time playback of MPEG-1, MPEG-2, DIVX and H.264 -encoded streams, with GPU-acceleration. Yet, when I clicked on the resulting animations, depending on which player I chose to play those with, I’d either obtain the video stream, or I’d just obtain a grey rectangle, replacing the captured video stream. And what I do know, is that which of these results I obtain, depends on whether I’m playing back the video stream using a software decoder purely, or whether I’m choosing to have the stream played back with GPU-acceleration.

I’ve run in to the same problem before, but this time, the cause was elsewhere.

Basically, this result will often mean that the player application first asks the graphics card, whether the latter can decode the stream in question, and when the VDPAU API responds ‘Yes’, hands over the relevant processing to the GPU, but for some unknown reason, the GPU fails to decode the stream. This result can sometimes have a different meaning, but I knew I needed to focus my attention on this interpretation.

Linux users will often need to have some sort of file-format, in which they can store arbitrary video-clips, that do not need to conform to strict broadcasting and distribution standards, even when the goal is ‘just to monkey around with video clips’.

I finally found what the culprit was…

(Updated 8/15/2019, 22h15 … )

Continue reading VDPAU Playback Issue (Problem Solved).

Ripping DVDs with Linux

I just recently received a DVD which a relative of mine from Germany, had authored privately in 1994, and when I did, my first concern was not so much to watch the whole footage, but rather of archiving it. In 1994 it was very trendy, to compose our own menus for Movie-DVDs and so forth. But these days, optical storage may no longer be the ideal solution to archiving footage.

And so in principle, archiving means ‘ripping’, and then storing on some other medium, which I hope to be more permanent.

Under Linux, it is quite possible to rip DVDs. One way that has existed for a long time, has been just to use the Graphical User Interface of “K3b”, which depends on having the package ‘transcode’ installed. But there is a recent behavior of K3b which many people have noticed. This program will only rip properly, to the ‘DivX’ format. The ‘MPEG4′ format is temporarily out of order within this application. And, DivX is known to be an inferior format.

And so one solution which worked for me, was first to use K3b in order to make an ISO File of the DVD, and after that to tell another GUI application named “Handbrake” to open that ISO File. For me, that did the trick well. Handbrake will offer to store the titles in M4V Files by default, which is just another naming for MP4 Files, that are H.264-compressed in either case. Or it will allow us to store them in ‘Matroska’ (MKV) Files.