MHEG Captions
#1
[size=150]Could someone explain to me how MHEG Captions worked, as in how they were generated/transmitted?[/size]

Is it by chance the same technology that Red Button would have transmitted the small images it would show occasionally? Only a guess.

See:
https://duckduckgo.com/?q=MHEG+captions&...iax=images
https://www.youtube.com/watch?v=lD5zN74wM2A&t=8s
I'd also like to note that's it's a nice way to show something to the viewer before broadcasting begins

Thank you!
#2
Yeap, spot on.

Same technology. When the channel switched to its off-air state, the pointer to where the MHEG app should auto-boot changed from the "Maybe show the red button and wait for Red/Text to be pressed" scene to the "This channel is offair" scene.

When the channel came back on air, it would switch back.

(From memory that pointer was the DSM-CC Service Gateway object, which kinda acted like a hard disk mount point, but in the virtual carousel filesystem... Heh, those are dusty memories!)
#3
Hi [mention]Flooski[/mention], thanks!

Is the virtual carousel filesystem the information for each screen or page?
So if the user selects page 123, or the station is off-air, it'll pull the information from the broadcast a bit like CEEFAX? Am interpreting that correctly? I'm just going off the little information I can find on the internet, haha
#4
Lewis post_id=675 time=1617045536 user_id=1064 Wrote:Hi [mention]Flooski[/mention], thanks!

Is the virtual carousel filesystem the information for each screen or page?
So if the user selects page 123, or the station is off-air, it'll pull the information from the broadcast a bit like CEEFAX? Am interpreting that correctly? I'm just going off the little information I can find on the internet, haha

As best I understand it, yeah, that's exactly right, it's like Ceefax/teletext. The carousel is repeatedly transmitted over and over, and the receiver would (when instructed to, either by the transmission or the user) sit and wait for the relevant files (like pages on teletext) to come around on the cycle of transmitted files. Much like teletext, MHEG-5 (or any of its competition, as Sky and cable didn't use it) was a transmit-only technology as far as TV goes, so you couldn't actively request a file as on the internet, it just beamed a series of files at you and you'd grab the one you wanted as it arrived.

On cable that was somewhat different, it used Liberate middleware which had web-based interactive applications. That didn't necessarily mean that you could request files as on the internet, more that it used HTML and JavaScript to build and present the interactive stuff, but cable also had the advantage of being a two-way medium. Because of that, it was possible (though not necessarily always used) to implement a more internet-like request and respond system, so you could actually pull files as you needed them rather than wait for them to come around in a linear stream.
#5
Hi @Lewis,

Yes... and no. It depends on how you look at it.

Here's what happens (I'm skipping over a lot, but hopefully it makes sense):

The MHEG engine works with files and directories, just like on a windows/mac/linux computer. There are code files, image files, text files etc. but they're all just files in directories. The broadcaster writes code that pulls data (news stories, weather maps etc.) out of this filesystem and shows it onscreen. So from this angle, the virtual filesystem looks just like a normal computer's filesystem.

However... how does the data actually get to the box? - That is done with an ever-looping carousel. The filesystem that describes the red button service (files, directories, mountpoints etc.) is carefully chunked up into modules, and a carousel playout machine plays those modules out in a loop.

Some of these modules — the really important ones that you want to display super-quick when someone tunes to your channel (such as the Red button image, the "this channel is off air" text and the code that displays it) — are played out lots of times per carousel cycle so they arrive at the box very quickly.

So from this angle, it looks like a carousel! Smile

When the box first tunes to a channel, it knows nothing other than where to look for the carousel data. Usually the filesystem is deleted from the box when you tune away. As the modules arrive, the box pieces together the virtual filesystem as it goes along. That means that the box doesn't have to download the entire carousel (and figure out the entire virtual filesystem) before it can start showing interactive content. If the MHEG code wants data that hasn't arrived yet, it just waits for it to turn up in the carousel and once it does, it adds it to the virtual filesystem and the red button code can use it. Back in the day, boxes didn't have enough memory to hold a large carousel, so they were forever downloading new stuff and disregarding data they didn't need. Modern MHEG boxes just quietly download everything because they have the space and it's easy.
#6
Oh wow! Thank you [mention]settopboxing[/mention] and [mention]Flooski[/mention]!
I understand!

https://imgur.com/kxwyBHY
For the local generation, from what I've pieced together (very basically) this is what happens:

1. Reads the yellow section of different elements and their locations, draws them on screen
2. Downloads the font and points the text elements to use that when drawn
3.Reads the palette (orange) to fill the colours of the elements
4. Reads the green section, works out which elements are links and what they do when activated

I invite you to correct me!

[size=50]Source: http://mheg5.net/down/class.pdf[/size]
#7
settopboxing post_id=688 time=1617046213 user_id=1116 Wrote:On cable that was somewhat different, it used Liberate middleware which had web-based interactive applications. That didn't necessarily mean that you could request files as on the internet, more that it used HTML and JavaScript to build and present the interactive stuff, but cable also had the advantage of being a two-way medium. Because of that, it was possible (though not necessarily always used) to implement a more internet-like request and respond system, so you could actually pull files as you needed them rather than wait for them to come around in a linear stream.

I'll have to look into this. Very interesting to me for boxes to literally use the internet! The main thing I can think of that did this sort of thing would be Sky.
#8
Heh, that's right [mention]Lewis[/mention], but you've found a very complex definition!

I'd recommend looking at it from the point of view of the person writing the MHEG code.

There's two parts to making an MHEG service work: the MHEG App and one or more MHEG Scenes.

The MHEG App is code that runs all the time on a channel, so it's all the stuff that you want to keep available for use during the lifetime of the application (think global variables, if you're a programmer). The first thing the MHEG App does is load in an MHEG Scene. Scenes can be swapped in and out, but you can only have one active at any time. MHEG Scenes are code specific for the type of "page" the viewer is on. There could be unique MHEG Scenes for every single Red Button Page, or there might be unique MHEG Scenes for each type of page (news, menus, weather, off-air messages etc.).

Have a look at this Hello World example of an MHEG App and Scene: http://digvid.info/mheg5/hello_world.php

In the MHEG Application shown there, there's a ":link" (a bit of code that runs for some reason). The "IsRunning" is the event that causes that code to run, and "IsRunning" means "when the MHEG App first starts". The code that's run loads ("transitions to") the "~/hello.mhg" MHEG Scene.

This hello.mhg MHEG Scene has a textbox on it that says Hello World.

I believe the reason for this split between MHEG Apps and MHEG Scenes was down to the limited memory on early MHEG receivers. They couldn't hold all of the code that describes how to render a red button service, so they swapped the bits of code in and out as required.
#9
Lewis post_id=707 time=1617047526 user_id=1064 Wrote:I'll have to look into this. Very interesting to me for boxes to literally use the internet! The main thing I can think of that did this sort of thing would be Sky.

Sky was a sort of middle ground in that all the interactive applications, games, etc were delivered by satellite in much the same way as the MHEG-5 stuff described above, but it did have a telephone connection too. The telephone connection was never, to my knowledge, used to download application code/data, but could be used to buy tokens for paying non-free games or, perhaps a more obvious use, ordering pay per view movies/sports and such. So the applications couldn't request data that way, but they could charge people to use/play them, which ONdigital couldn't do (as far as I'm aware - the ONdigital boxes did have modems, but I think they were only used for ONmail email service).
#10
Flooski post_id=720 time=1617048368 user_id=1223 Wrote:Heh, that's right [mention]Lewis[/mention], but you've found a very complex definition!

I understand that quite well now, thanks! I see how your description and the link you sent line up with the flowchart.
It's cleverly done and very interesting!

Would the App contain the controls in green and the Scene, the content, in pink?
https://imgur.com/TpbAZd9

How about for the menu?
Is this a seperate App, with similar controls/context seperation?
https://3.bp.blogspot.com/-7cH4EoVQL8I/U...CRB100.png

[size=50]Sources: http://teletextart.co.uk/teletext-r-podc...e-controls
http://www.a516digital.com/2013/02/red-b...eview.html[/size]
#11
Ha, that's getting a bit specific, but maybe stuff like the broadcaster logo, the "( )" pagenumber image and the object that controls the video image (where it's placed, what size it is etc.) would sit in the MHEG App (because they're probably used across multiple scenes). The rest of what you see probably/maybe sits in the unique scene for each type of screen.

It all depends on how the person that wrote the code designed it - you'd have to ask them! Tongue
#12
Flooski post_id=739 time=1617049486 user_id=1223 Wrote:It all depends on how the person that wrote the code designed it - you'd have to ask them!

I imagined it'd be something like that!
Thanks for explaining it to me so well. I've always wondered how they did this. It's simply, a couple bitmaps and geometric shapes being drawn in certain places, and some of them can do things!

I was surprised that it was in a filesystem layout in folders. I certainly wasn't expecting it to be that way, though I didn't really have any expectations beforehand! That website you linked had a space invaders example code, and i downloaded that and had a flick through. It's less complex than I'd have thought at a basic level, and surprisingly human readable! Through that ZIP download, Did I see the folder layout you'd presumably see "at the server end" of the broadcast chain?

I did try to run it using some "MhegPlus.MhegPlayer-1.0.1a.jar", but had no luck trying to get it to play ball. It was BBC branded though!

Thanks again :)
#13
A pleasure Smile I steamed through a lot of stuff, so if there's anything I didn't explain well, do say and I'll try again.

Yes, the server filesystem would often look very similar / the same to the virtual one. It didn't have to, but it makes it less confusing!

All the cool kids are writing HbbTV apps (written in HTML and JavaScript) these days to do similar (and better looking) things in the world of interactive TV.

HbbTV can optionally use the same virtual filesystem magic (known as DSM-CC Object Carousel) to download data over the air, so similar technology to that which sat in those OnDigital boxes lives on to this day! Big Grin
#14
HbbTV seems to be the replacement for MHEG-5.
By the looks of it, HbbTV is the framework for the Freesat EPG / Freeview Play GUI, just like MHEG did the EPG beforehand.

It's insane how MHEG has been used for yonks for both EPG and teletext and has stood up until even now, though the BBC are barely hanging on to it. It seems quite versatile!

By any chance, do you know how the new Red Button GUI on Sky Q works? Is that going to be a similar HTML based system?
#15
Lewis post_id=743 time=1617050154 user_id=1064 Wrote:just like MHEG did the EPG beforehand.

It would have been rare for a box to use MHEG to render the EPG.

In the UK at least, the MHEG engine didn't have access to the broadcast schedule data. Plus for something as complex as an EPG grid, receivers of that era would struggle to render quickly if it were doing so in MHEG. Usually boxes rendered the EPG and their settings menus etc. in their own (small, swift) graphical environment that rendered fast and could access the schedule data directly from the multiplex.

There may well be boxes that did use MHEG for the native EPG, but they're in the minority.

As for Sky Q: i don't know, I'm afraid.


Forum Jump:


Users browsing this thread: 1 Guest(s)
Powered by MyBB, © 2002-2026 MyBB Group. Theme designed by m0ckingbird © 2015-2026.