DVDs (and why I rip them)

Taken to Aldershot…

Most copy protection schemes are varying degrees of annoying.

A non-software example. DVDs. The main reason I rip is to watch on my phone (I don’t have a TV, I have a composite video to VGA adapter and a flat panel monitor).

But two things really seriously bug the hell out of me:

• British DVDs. That stupid anti piracy “you wouldn’t steal a car” advert that you cannot skip watching. Given that is being shown to a legitimate owner of the DVD (a pirate would just omit it), it’s borderline offensive. And it makes me feel like I should go and steal a car, a granny, and whatever else just to give that advert the middle finger.
• French DVDs. Have a very big habit of “audio as a French dub” or “original English with subtitles you can’t turn off”. I can perfectly easily turns the forced subs off with SMPlayer, so why can’t I do that on my portable DVD player? You, distributor, are also insulting French people that may be good enough at English that they don’t need the subtitles.

[I usually watch movies with subtitles on, a habit from the days of 888, I still do it with Netflix; but most DVD subs are an exercise in “how can we make this unbelievably UGLY”?]

that you cannot skip watching

About what seems like 100 years ago, I made sure that before I purchased a DVD player that the firmware could be hacked to remove the UOP (User Operation Prohibition) so that these things could be skipped. I also made sure that it could be made multi region.

With RiscOS games etc. the first thing that I would always do was to remove the “protection”.

subtitles on, a habit from the days of 888

Me too, I also often have the Audio Description switched on as well!

Me too, I also often have the Audio Description switched on as well!

Subs are useful, especially with the modern trend of mumbling dialogue that’s barely audible over the background music.

Something went above and beyond. The other day, on Netflix, I was watching something – it might have been Spectros which, if it was, needed subs being in Brazilian Portuguese (English dub available, but I tend to avoid those). Anyway, there was a scene of somebody making a phone call. Seen through a window. With the dialogue inaudible (because window) and the subs faithfully transcribing it all.

Other amusing ones are where swear words are muted or, worse, switched out for lesser words. But not in the subs. ;-)

I don’t use audio description. I was watching something on… I think it was BBC One a couple of years back, and the satellite receiver gave me the choice of English or Described. So I switched to described and tried to keep a straight face as I saw a door slam shut, heard a door slam shut, and then a disembodied voice that sounded bored cut in to say “door slams closed”.

Sometimes I get descriptions on Netflix subs. Like “perky music” or “low growl” or “woman screams”.

I made sure that before I purchased a DVD player

The first one I ever bought, when DVDs were a new thing (and I got it just to watch Fly Away Home) had a complicated sequence to enter on the remote control to switch region.

All the DVD players since then have been picked up from boot sales and the like, so not much chance of choosing for features. More a case of buying it if the price is right [or as in the case of earlier in the year, turning it down even for a mere fiver because of a missing remote – I know that many DVD players are next to useless without the controller]

I rip to watch on Ti with mplayer or Kino.
Have play around with Adrian Lees DeCSS sources (thanks Adrian for this) but at this time it looks like I’m to stupid to make it usable. If anyone will help…

DVD is old school, but sill very common.

I wonder if Cino could play a DVD with a modern computer. Or at least play the ripped MPEG2.

Technically anything from the Pi2 onward ought to have enough grunt to decode SD MPEG-2 (DVDs) in software.

But…alas…technically RISC OS uses only one of the four cores, so the question becomes “is one core capable?”.

Probably the way to find out is to copy a VOB file to media and see if anything plays it satisfactorily.

But…alas…technically RISC OS uses only one of the four cores, so the question becomes “is one core capable?”.

I’ve no idea how far Jeffreys work on multicore support has progressed but if it’s merely at a throw a task at a second core and let it run stage then the distinction between the player front end and the back end ‘engine’ is probably important.

Well… Just about to start watching Anon. A little notice at the top left said “Rated 16+” and “Violence”. Then a few seconds later “THIS PROGRAMME CONTAINS PRODUCT PLACEMENT”. Never seen that before, so either Netflix has changed something, or the placement is so damned blatant that they’re calling themselves (it’s a Netflix film!) out on it.

Cino plays DVD streams at around 18-20fps on a single-core Cortex-A9 device such as the ARMX6/WandBoard without any hardware acceleration, and the code is entirely XScale-era, ie. no use of NEON acceleration presently. The colour space conversion/upsampling can definitely be accelerated using NEON, and that change alone would probably attain the requisite 25fps. Ideally, YUV overlay hardware would do this to reduce further the CPU load; a GraphicsV API extension was introduced by Jeffrey to facilitate this, although I don’t know how far it’s progressed on the various targets.

The real sticking point on the XScale’s IOP321 was the memory access latency of the CPU when missing in L1 Dcache, heavily impacting the B-frame prediction code, but more recent SOCs have a L2 cache and a lower-latency memory system so they perhaps wouldn’t even need any reworking of that code.

In short I believe fully software DVD playback to be attainable on all of: PandaBoard, Pi3/ARMbook, WandBoard/ARMX6/ARMini.m even with a single core, and perhaps even the BeagleBoard/derivatives. At the show KinoAMP was playing full screen on the Titanium (albeit with the occasional frame drop) and on the Pi4.

Sorry, it looks like my description was not clear.
Normally I use the ripped vob files with mplayer (comes without DVDnav option) or Kino(Amp) in a playlist from harddisk.
On Ti unprotected DVDs are usable from optical drive but also in a playlist.
Cino I have try. “Works” on Ti without AudioMPEG (module not works) and play the DVD files from HDD 2-3 times faster. On MX6 are also a bit to fast without AudioMPEG.
I remember I have play around on BeaglexM long time ago. 5.17 ROM was actually. Without AudioMPEG it works nearly with normally speed but with activ AudioMPEG module it was very, very slow.
Off topic… I play around with a DVB-HAT on Pi 4. In DE it needs the H.265 hardware encoding to watch TV. Works fine with Raspian. Is it possible to use the hardware encoding (H.264, H.265) in RISC OS?

In short I believe fully software DVD playback to be attainable on all of: PandaBoard, Pi3/ARMbook, WandBoard/ARMX6/ARMini.m even with a single core, and perhaps even the BeagleBoard/derivatives. At the show KinoAMP was playing full screen on the Titanium (albeit with the occasional frame drop) and on the Pi4.

Dunno for other machines as I only have a Pi3, but on that machine before any support for hardware overlays or NEON, KinoAmp was able to replay DVDs at full speed if you didn’t apply any scaling (and with occasional hiccups due to disc access). On the other hand bi-linear interpolation scaling to the even nearest available resolution dropped the frame rate to something like 60%. Since then, thanks to Jeffrey we have overlays which make YUV→RGB conversion and scaling to Full HD a breeze.

Unfortunately overlays are far from enough to decode Full-HD MPEG2s so I added some optimizations to IDCT, motion compensation and de-interlacing. Even so I could only get between 13 and 18 fps on the MPlayer test samples. It should still help the replay of DVD on older machines, since the 60% is what I get now for bi-linear scaling to Full HD in the absence of overlays.

scaling to the even nearest available resolution dropped the frame rate to something like 60%

I presume this is software scaling up to FullHD?

I wonder how fast it would be capable of if using no hardware mode changes, selecting a resolution under RISC OS that is close to native DVD (720×576 ought to fit into 800×600), plotting directly into that, and leaving it to the GPU to scale it up to monitor resolution…?

[I think this topic is in danger of needing to leave Aldershot!]

I think this topic is in danger of needing to leave Aldershot!

# You can check out any time you like, but…

You are Glenn Frey, and I claim my £5

Ideally, YUV overlay hardware would do this to reduce further the CPU load; a GraphicsV API extension was introduced by Jeffrey to facilitate this, although I don’t know how far it’s progressed on the various targets.

Support is implemented on the Pi, OMAP3, OMAP4, and OMAP5. Implementing it for the Titanium will be a job for Elesar, due to the closed-source nature of the video driver. Iyonix support is buried somewhere in my todo list (there’s some code in the BeOS driver for configuring the overlays). I can’t remember the details offhand, but iMX6 support will be tricky. Not sure about the ARMbook.

This thread has also reminded me that I still need to update the companion VideoOverlay module to add proper official for using overlays from single-tasking programs.

@André – there may be faster ways to upscale the image in sw. nearest-neighbour resampling can be done most quickly in my experience by something akin to:

 for (x = 0; x < w; x++)
   colOffset[] = ;
 // Noting that the selection of source columns is invariant w.r.t. scanline...
 for (y = 0; y < h; y++)
   for (x = 0; x < w; x++)
     pDest[x] = pSrc[colOffset[x]];

so in assember the inner loop becomes just:

  LDR off,[offsets],#4
  LDR pix,[src,off]
  STR pix,[dst],#4

that’s per-pixel of course, and in reality you’d want to advance the LDR instructions, use as many registers as possible, and delay the use of those registers…by interleaving the processing of n separate pixels, doing a batch of n pixels at a time.

And for bilinear interpolation, as you probably know, use a separable kernel, performing the vertical interpolation first to reuse as many intermediates/calculations as possible as you move along the scanline, and for the horizontal interpolation instead of the ‘obvious’ approach:

you can rearrange as:

or in practice:

where wmod is w as m.n fixed-point weighting

@Adrian
For nearest-neighbour scaling I use:

    mov     r9, r2, asr #frac       ; (int)Xoffset
    ldr     r9, [r14, r9, asl #2]   ; pixel = *(src_addr + (int)Xoffset(words))
    add     r2, r2, r0              ; increment Xoffset
    str     r9, [r12], #4           ; display pixel

so its probably a matter of how fast the extra ldr compares to mov + add.

Regarding bilinear interpolation, the rearrangement to use a single multiplication is actually conterproductive for 2 reasons:
- we are not in the era of the ARM6 anymore were multiplications are slow, IIRC for StrongARM mutiplying by a value in range [0-1023] is performed in a single cycle.
- (x0-x1) may produce negative values which prevents you to handle two color componants at the same time. I separate the four bytes of a pixel (rgba, argb, bgra, …) p3 p2 p1 p0 into two variables 00 p2 00 p0 and 00 p3 00 p1, which let me interpolate by 256 steps on two color componants at the same time.

Anyway I have just finished the neon version of bilinear scaling. The following tests we performed on a Pi3 with audio off, all frames shown without delay (no syncing, ignoring the timestamps) scaled to 1920×1080. The summaries give an idea of how neon code helps in various part.
To understand better:
- video corresponds to the decoding of the MPEG stream. Neon is used here for idtc and motion compensation.
- drawer performs deinterlacing and YUV→RGB conversion (or in case of overlays to whatever the overlay uses). Neon is used for deinterlacing.
- scaler performs the bilinear scaling to screen. This is the part I am converting to neon in my current development version.

Neon code:
---------

Video:
MPEG 2, Size 720 x 576 i, Pixel aspect ratio 64:45
Bitrate 8700 Kbit/sec, YUV420
1642 Frames (I=127 P=505 B=1010) 25.00 fps
1642 (+0) Frames (100.00%) displayed (I=127 P=505 B=1010) 28.18 fps
16m (BGR) Colours, Magnification x=266.7% y=187.5%

Time:        5243893 (58.27 seconds)
fread   =     402305 ( 7.67%)
demux   =      41740 ( 0.80%)
audio   =        150 ( 0.00%)
video   =    1144524 (21.83%)
drawer  =    1006257 (19.19%)
scaler  =    2626151 (50.08%)
sync    =          0 ( 0.00%)
wait    =      13923 ( 0.27%)

Neon deactivated:
-----------------
Video:
MPEG 2, Size 720 x 576 i, Pixel aspect ratio 64:45
Bitrate 8700 Kbit/sec, YUV420
1642 Frames (I=127 P=505 B=1010) 25.00 fps
1642 (+0) Frames (100.00%) displayed (I=127 P=505 B=1010) 17.54 fps
16m (BGR) Colours, Magnification x=266.7% y=187.5%

Time:        8425103 (93.61 seconds)
fread   =     434248 ( 5.15%)
demux   =      36660 ( 0.44%)
audio   =        178 ( 0.00%)
video   =    1757851 (20.86%)
drawer  =    1162691 (13.80%)
scaler  =    5010891 (59.48%)
sync    =          0 ( 0.00%)
wait    =      13978 ( 0.17%)

Neon + overlays:
---------------
Video:
MPEG 2, Size 720 x 576 i, Pixel aspect ratio 64:45
Bitrate 8700 Kbit/sec, YUV420
1642 Frames (I=127 P=505 B=1010) 25.00 fps
1642 (+0) Frames (100.00%) displayed (I=127 P=505 B=1010) 70.85 fps
YV16 Colours, Magnification x=266.7% y=187.5%

Time:        2085887 (23.18 seconds)
fread   =     193038 ( 9.25%)
demux   =      36330 ( 1.74%)
audio   =        139 ( 0.01%)
video   =    1157595 (55.50%)
drawer  =     641613 (30.76%)
scaler  =      34184 ( 1.64%)
sync    =          0 ( 0.00%)
wait    =      14444 ( 0.69%)

The neon optimisation nearly halves the scaling time (which seems consistent with other neon optimised parts when I timed them) and in pratice lets me display around 90% of the frames of a video making it very watchable. Of course it doesn’t old a candle to the use of overlays (it around 2.5 times faster in the test).

One funny unxepected side effect of the overlays in is an appaent speedup of the disc access. This does not occur in a normal play so my guess is that reducing the time spent between discs accesses affects the performance of this old harddisc.

@André I did read the KinoAMP upsampling kernel before posting. Whether the two LDRs or one+two DP instructions is faster perhaps depends upon the microarchitecture these days because of the parallel internal pipes.

On a Cortex-A15 there are two arithmetic pipes and two load/store so perhaps out-of-order execution and register renaming allows it to absorb the extra instructions but, of course, the short list of ‘offset’ values in the three instruction approach will be small enough that it just sits in the cache so on simpler ARMs I’d certainly expect it to be cheaper, provided that you interleave the processing of multiple pixels as suggested. Similarly, dropping multiplications is useful if you are suffering from the /latency/ of the result, which is of course higher than the single cycle /throughput/.

On the register renaming front, interestingly in the Cortex-A72 TRM, ARM recommends the use of a simple “LDRD r3,r4,[r0,#off]:STRD r3,r4,[r0,#off]” for implementing memcpy/memmove, with no use of more than those two data registers even though the sequence is repeated 8 times. A telling example of how the optimisation rules change over the years ;)

I take your point about operating on multiple components of already-interleaved data – a trick I’ve used myself in the past – but I think for maximal performance you’d ideally be operating on the sub-sampled YUV planar out of the decoder core, and performing both colour space conversion and then upsampling as a single operation on-the-fly without storing out any unscaled RGB data. That’s the software-only case, of course, and I realise that it likely doesn’t fit well with the current structure of the software.

As you note, hardware overlay is obviously the way to go; believe me I spent enough time writing tuned per-pixel processing software for video feeds in my previous employment and bemoaning the fact that “this really isn’t a job software should be doing!”

I take your point about operating on multiple components of already-interleaved data – a trick I’ve used myself in the past – but I think for maximal performance you’d ideally be operating on the sub-sampled YUV planar out of the decoder core, and performing both colour space conversion and then upsampling as a single operation on-the-fly without storing out any unscaled RGB data. That’s the software-only case, of course, and I realise that it likely doesn’t fit well with the current structure of the software.

Structure wise I have already 2 separate ways with YUV → RGB conversion followed by scaling and YUV → overlay format so it should not be too difficult to cope with a third one. The issue is that the YUV → RGB is already just barely in term of number of registers: 3 planes (Y, U, V), destination, 3 conversion tables (standard conversion adjusted with brightness, contrast and color settings), loop counters, that is just enough for work registers.

One possibility to explore for the bilinear scaling case: perform the vertical scaling in YUV mode while at the same time switching from planar YUV to a packed format and use that as input for horizontal scaling and conversion to RGB.