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).

How the EPUB2 and MOBI formats can be used for typeset Math.

According to This preceding posting, I was experiencing some frustration over trying to typeset Math, for publication in EPUB2 format. EPUB3 format with MathML support was a viable alternative, though potentially hard on any readers I might have.

Well a situation exists in which either EPUB2 or MOBI can be used to publish typeset Math: Each lossless image can claim the entire width of a column of text, and each image can represent an entire equation. That way, the content of the document can alternate vertically between Text and Typeset Math.

In fact, if an author was to choose to do this, he or she could also use the Linux-based solutions ‘LyX’ , ‘ImageMagick’ , and ‘tex4ebook’ .

(Edited 1/9/2019, 15h35 … )

Continue reading How the EPUB2 and MOBI formats can be used for typeset Math.

Web-Optimizing Lossless Images

One subject which has caught my interest in recent times, is how to publish lossless images on the Web – and of course, optimize memory-use.

It has been a kind of default setting on most of my desktop software, that I’ll either save images as JPEGs – that are lossy but offer excellent file-sizes – or as PNG-Format files – that are losssless, but that still offer much better file-sizes than utterly uncompressed .BMP-Files would offer. Yet, I might one day want even smaller file-sizes than what PNGs can offer, yet preserve the crisp exactitude required in, say, schematics.

The ideal solution to this problem would be, to publish the Web-embedded content directly in SVG-Files, which preserve exact curves literally at any level of magnification. But there are essentially two reasons fw this may not generally be feasible:

  1. The images need to be sourced as vector-images, not raster-images. There is no reasonable way to convert rasters into vector-graphics.
  2. There may be a lack of browser-support for SVG specifically. I know that up-to-date Firefox browsers have it, but when publishing Web-content, some consideration needs to be given to older or less-CPU-intensive browsers.

And so there seems to be an alternative which has re-emerged, but which has long been forgotten in the history of the Web, because originally, the emphasis was on reducing the file-size of photos. That alternative seems to exist in GIF-Images. But there is a basic concern which needs to be observed, when using them: The images need to be palletized, before they can be turned into GIFs – which some apps do automatically for the user when prompted to produce a GIF.

What this means is, that while quality photos have a minimum pixel-depth of either 24 or 32 Bits-Per-Pixel (‘BPP’), implying 8 Bits Per Channel, and while this gives us quality images, the set of colors needs to be reduced to a much-smaller set, in order for GIFs actually to become smaller in file-size, than what PNG-Files already exemplify. While 8-bit-palletized colors are possible, that offer 1/255 colors, my main interest would be in the 4-bit or the 1-bit pallets, that either offer the so-called ‘Web-optimized’ standard set of 16 colors, or that just offer either white or black pixels. And my interest in this format is due to the fact that the published images in question are either truly schematic, or what I would call quasi-schematic, i.e. schematic with colors.

What this means for me as a writer, is that I must open the images in question in GIMP, and change the ‘Image -> Mode’ to the Web-optimized, or the 1-bit Pallets, before I can ‘Export To GIF’, and when I do this, I take care to choose ‘Interlaced GIF’, to help browsers deal with the memory-consumption best.

In the case of a true 1-bpp schematic, the effect is almost lossless, as the example shown below has already occurred elsewhere in my blog, but appears as sharp here as the former, PNG-formatted variety appeared:

schem-1_8

In the case of a quasi-schematic, there is noticeable loss in quality, due to the reduction in color-accuracy, but a considerable reduction in file-size. The lossless, PNG-format example is this:

quasi-schem-1_1

While the smaller, GIF-format File would be this:

quasi-schem-1_9

There is some mention that for larger, more-complex schematics, GIFs take up too much memory. But when the image really has been large in the past, regardless of what I might like, I’ve been switching to JPEGs anyway.

There could be some controversy, as to whether this can be referred to as lossless in any way.

The answer to that would be, that this results in either 1 or 4 bit-planes, and that the transmission of each bit-plane will be without alteration of any kind – i.e., lossless. But there will be the mentioned loss in color-accuracy, when converting the original pixel-values to the simplified colors – i.e. lossy.

Continue reading Web-Optimizing Lossless Images