An excerpt from a book that I have to refer sometimes (here’s the source, it really tells a lot about proper relationship. Ask a nearby German for a translation if you need it.
P.S. Next post will be about a codec technical description, I promise.
An excerpt from a book that I have to refer sometimes (here’s the source, it really tells a lot about proper relationship. Ask a nearby German for a translation if you need it.
P.S. Next post will be about a codec technical description, I promise.
Italy is a good country (piecewise) — nice scenery, decent food (and pasta), nice architecture…
There’s but one thing that annoys me, I think you’ll be able to spot it on those two pictures.
Milan, a corner of via Vitruvio and via Benedetto Marcello.
I cannot say it for sure but I remember Ukrainian markets (right after closing time) being cleaner than that.
There are enough general use standardised codecs, there’s even VPx family for those who want more. But there are not enough niche codecs with free/open specifications.
One of such niche codecs would be an intermediate codec. It’s suitable for capturing and quick editing of video material. Main requirements are modest compression rate and fast processing (scalable is a plus too). Maybe SMPTE VC-5 will be the answer, maybe Ogg Chloe, maybe something completely different. Let’s discuss it some other time.
Another niche codec that desperately needs an open standard is screen video codec. Such codec may be also used for recording webcasts, presentations and such. And here I’d like to discuss a whole family of such codecs based on the same coding principles.
It makes sense to make codec fast by employing multithreading where possible. That’s why frame should be divided into tiles that should be not so large and not so small, maybe 192×128 pixels or so.
Each tile should be coded independently, preferably its distinct features coded separately too. It makes sense to separate tile data into smooth features (like gradients and real life pictures) and sharp transitions (like text and UI elements). Let’s call the former a natural layer and the latter a synthetic layer. We’ll need a mask to tell which layer to use for the current pixel too. And using these main blocks and employing different coding methods we can make a whole family of codecs.
Here’s the list of example codecs (with a random FOURCC assigned):
J-B0
— employ JPEG for natural layer and J-B1
— employ Snow for natural layer coding and FFV1 for synthetic layer coding;J-B2
— employ JPEG-2000 for natural layer coding, JBIG for mask coding and something like PPM modeller for synthetic layer;J-BG
— employ WebP for natural layer and WebP LL for synthetic layer.As one can see, it’s rather easy to build such codec since all coding blocks are there and only natural/synthetic layer separation might need a bit of research. I see no reasons why, say, VLC can’t use it for recording and streaming desktop for e.g. virtual meeting.
So what I’ve discovered today.
There’s a Schwarzwaldbahn going through Schwarzwald from Offenburg to Konstanz and there’s a station there — Villingen. That station bears a plaque that it had 10000th kilometre of electrification of DB network done in 1975 (DDR railways on the other hoof lost most of its electrification after the war because it was more important to electrify Soviet railways but that’s another story).
And there’s a branch connecting Villingen (Baden) with Rottweil (Württemberg) — unelectrified. And that branch has its own subbranch to Trossingen Stadt. That subbranch is also served by a diesel railbus. But unlike the branch it connects to it’s electrified! And that electrification is used only by museum vehicles from 1930s-1960s that are electric only (or in one case it’s a carriage with an electric locomotive).
On most such lines in Germany one usually has trains hauled by a steam locomotive or a diesel rail buses and the main traffic is electrified but in this case it’s the other way round. I have only one possible explanation — Württemberg.
P.S. Still it’s hard to find stupider situation with electrification than in Denmark. The only countries it has connections to had chosen 15 kV 16? Hz system. Denmark settled on 25 kV 50 Hz. But looking at their other railway-related decision (i.e. IC4) it seems logical.
P.P.S. For Ukraine the situation is sadder — once I was in Uzhgorod-Kharkiv train and it had to change locomotive twice because there are two electrification systems there (which make three areas). They claim it was done to better account for relief, i.e. different electrification for the flatter and mountainy regions. Hopefully there will be more two-system trains in the future (and there will be the future too).
I think most of you have read this piece of news about G**gle VPx plans already. After some thoughts I’ve decided to comment on it as well.
So, here’s a bit of history:
It is easy to see that there’s a huge issue to deal with if they want to release a new VPx every 18 months — they should have a corresponding ITU H.26x standard (or at least some draft of it) available. The only alternatives are polishing VP9 and calling it a new version when some incompatible feature is added or start ripping off Daala, Dirac and Bink 3. Good luck.
More than two years ago I’ve posted what I considered should be high priority Libav projects. Let’s see what has been finished, what’s left and what should probably be added.
avserver
libswscale
replacement. The one that doesn’t sap sanity when you look at its code. Maybe with a nicer API too. And better pixel format support.libavcodec/vc1dec.c
to put the fix there.G2M4
is done, the rest is permanently stalled (and I’ve passed stalling duties to Diego);So, if the tast was moderately interesting it was done, fringe stuff was not taken, serious stuff was not taken either (most people I know agree that swscaler should be replaced yet noone wants to work on the replacement).
And what high priority projects for Libav do I see in the future? None really. Just none.
I’ve not written anything about one of the crucial topics of this blog since ages, so here’s the long-awaited update.
Today I’d like to talk about probably the most interesting railway in Germany — Wutachtalbahn or Kursbuchstrecke 743 (Waldshut-Immendingen). It was build as a route to the South border of Germany that does not go on Swiss territory (the line along the Rhine it connects to goes through Basel and canton Schaffhausen).
Now, what makes it so interesting?
Despite being rather unimportant line nowadays and being about only 60km long (and there are no branches either!), it is operated by three different rail companies:
(Image shamelessly stolen from Wickedpedia)
So you have three different companies running trains on approximately 20km tracks. Is it the same rolling stock? Of course not!
SWEG runs class 650 (aka Stadler RS1) diesel unit, Deutsche Bahn employs class 641 diesel unit and WTB runs a steam locomotive (Württembergische T.14 or class 52.80 or something similar) with bunch of outdated carriages from various places (like Switzerland).
And for unknown reason it’s nicknamed “Pig’s Tail Railway” (see the map above, I have no clue why) and the name somehow appeals to me.
I’ve visited it in three parts: one year I saw the middle part, next year I saw the north parth and later I saw the last part too. Curiously, while DB runs the most modern train the route itself seems the most outdated: the rails are uneven so you can get a bit seasick, the signal system is implemented by driver’s assistant with a red flag who stands on the crossing while the train passes it and it does not stand on the Weizen station for long because it has to give room to the WTB train (in result it comes to the station, waits a bit and cowardly retreats back to the track and waits there till the WTB train is gone).
In general I’d recommend visiting it if you happen to be there. If you want to see something better — go to Sweden and try Uppsala-Lenna railway, it’s the best (now I want to visit it again — oh wait, I wanted that before too).
For the reasons I can’t disclose I really hate DTS codecs. For those who don’t know there are about three and a half codecs in this family:
You need to be Jean-Baptiste Kempf to love these formats: DTS Core uses annoyingly large tables, DTS Lossless relies on DTS Core part being decoded properly for it, DTS LBR is a special beast that I’ll describe below. And the best part — all those formats are poorly documented (tables are missing for DTS Core, something was missing for DTS Core X96k extension too, bitexact core reconstruction and some other things needed for real lossless decoder implementation are not documented, LBR is not much better either).
So, what makes DTS LBR special? Its coding mode of course. This is a weird codec that employs MDCT (nothing special so far), codes tones separately (that’s not so common) and spreads it all among many chunks for different resolutions that make it “scalable” or whatever.
Nevertheless this post is not about how horrible are all those codecs (if you have ever worked with them it’s obvious and Jean-Baptiste Kempf won’t believe anyway), it’s about obscure relations with other codecs.
When I looked at QDesign Music codec (unsupported by Libav currently) I found that it has suspiciously familiar coding scheme for tones (QDesign Music 1/2 also use tone detection in MDCT frames) — I’ve seen it in DTS LBR. And indeed, it seems the same guy created some codec called LBpack that was first to use that approach, then he was employed by QDesign and then by DTS. No wonder it looked similar.
Another piece of trivia — there was one guy working on so-called adaptive prediction and transform scheme. Later the prototype known as APT100 was turned into DTS Core. But looks like the same work gave birth to lesser-known codec APT-X (that I’m currently REing but that’s beside the point). And it’s not just the name — one codec employs QMF and ADPCM on subbands, another one employs QMF and optional ADPCM on subbands.
All that makes one wonder whether DTS Lossless is related to some lossless codec outside DTS (not necessarily APT Lossless but might be, no details are known about that one). Currently I cannot name any other lossless codec that employs the same coding approach (block coding with different coding for large and small coefficients plus non-adaptive filter). Of course such knowledge won’t change anything but it would be still interesting to know.
P.S. There are rumours that DTS LBR will be made scalable for adaptive streaming, what a fun that will be!
P.P.S. This post was written mainly to test how well new Mike’s setup works.
Short story: boring.
As I wrote more than a year ago the codec itself is rather simple and not that interesting (rather simple VLC coding plus DCT). Version KB2f
was floating point, KB2g
—KB2i
have switched to 16-bit integers wherever possible (including DCT, see links below). And I don’t really have content that I’d like to watch and unlikely to ever have it since my favourite games were released mostly before 2000 (that reminds me of Discworld Noir BMV format to RE…).
So here’s the list of what I’ve not done so far:
KB2f
;I’ll put known details to MultimediaWiki later.
All essential details about Bink 2g DCT are given here and here.
For those interested compressed patch is here.
P.S. I reserve right to look at newer versions if they appear and complain about them being equally boring.