Jump to content

Suggestion.: Add a tweak for old display of EPG technical data at the end of a position


Patryk F

Recommended Posts

Posted

Hi all,

I am observing the beta stuff for DVBViewer Pro.

In one of the last betas, there is a change regarding a way DVBViewer pro displays and handles technical EPG data at the end of an EPG position such as [Stereo} [deu}.

Since I am quite a technical guy and the old view was totally no problem for me, may we add a tweak to respect the old behaviour for incoming EPG data since it reaches the stable version?

Since it would be a technically oriented tweak, I would be happy if EPG display in the accessible, blind-oriented interface would  be also able to expose as much technical EPG info as possible.

Also, on a similar note, It would be nice if the visually impaired interface would be able to  include all the radio-text and other data available via UECP as a separate window accessible under a tab key to cycle between the EPG and Radiotext windows. preperably with the differentiable window handles/ control ID's for better exposure of both windows for programs grabbing the text from a window class.

Posted
15 hours ago, Patryk F said:

may we add a tweak to respect the old behaviour for incoming EPG data since it reaches the stable version?

 

Sorry, no. The old code has been removed and will not be reintroduced again. Sometimes it is inevitable to drop old stuff in order to keep the code straightforward and maintainable. Masses of options and resulting if... thens for every individual desire kill a program over time. There is already too much of it in DVBViewer.

 

15 hours ago, Patryk F said:

It would be nice if the visually impaired interface would be able to  include all the radio-text and other data available via UECP as a separate window accessible under a tab key to cycle between the EPG and Radiotext windows

 

I don't know what you mean by "other data available via UECP". Radio text is extracted from the ancillary data block of MP2 frames. There is no other UECP related processing.

 

Which channels offering radio text do you receive? The only ones I know are German and Swiss channels via satellite. The German channels on Astra 19.2° East, 12266 H, will drop radio text (at least in its present form) at the end of 2021, because they will switch over from MP2 to AAC audio. I don't know if there is a way to embed RDS data in AAC frames - never seen it up to now.

 

Another question is if dynamically changing text forms like radio text are suitable for screen readers used by visually impaired people. For example, DVBViewer does not update teletext pages dynamically when they are displayed in a text panel for the visually impaired. They remain static until the user switches over to another page.

 

Posted

 

In case of Teletext, the way it is handled now is great because this would make reading things complicated.

howewer In case of radiotext I can either stay in the window, and make the screen reader read to me on demand actually displayed text,

scenario nr 1.:

I am inside the read-only field, same as the main accessible window.

No matter whether the info inside the window is dynamic or not, screen reader would read it only if I press up or down arrow, as I would do when reading any text.

Then screen reader would read an actual information.

 

Scenario nr 2.: I can write a simple script inside the screen reader using it's API, to pay attention to a certain window class or certain control ID (the latter is more complicated but doable) and read if there is any new incoming text.

This one is quite disturbing since it requires a screen-reader level script but for power users is doable.

This way I can make for myself a script which autoannounces current song or whatever goes into the RT field.

 

 

Also, the separate window class instead of a classic TMemo but with all it's current  read-only edit field properties exposed would be great.

This would help me differentiate these both classes, since I may want RDS autoannouncement but not reading of a whole EPG main window view top to bottom when changing channel.

Also, It is sometimes usable to  have the exact same content as in a current accessible window or future RDS window written into txt file as it comes.

This way I can parse these data in various practical ways including reporting it to any internal audio encoder as a Icecast metadata or DAB fields when retransmitting or whatever.

 

So to sum this up, May I ask for a separate window cyclable through TAB key which would contain dynamically updated RDS / Radiotext content?

2. is it possible to, independently of the windows make a tweak or commandline switch to write content of both thecurrent accessible window  content and the RDS window content?

Filenames may be fixed, no problem for me.

 

 

Posted
On 6/19/2021 at 3:24 PM, Patryk F said:

May I ask for a separate window cyclable through TAB key which would contain dynamically updated RDS / Radiotext content?

Also, It is sometimes usable to  have the exact same content as in a current accessible window or future RDS window written into txt file as it comes.

 

It's quite a lot that you want, requiring time-consuming basic changes. However, you are the only one who requested something like this up to now. So the cost-benefit ratio is quite bad. Since we only have few resources, we have to look at what is really necessary and what is doable in a reasonable amount of time.

 

I think, first there is an overriding task: Checking what happens with radio text after the switchover of German satellite radio channels from MP2 to AAC. In the meantime I've found out that AAC frames also provide an ancillary data field where radio text can be stored. This may require a new implementation of radio text capturing. As you will understand, there is not much use for a text-based output in the UI if the radio text can't be received. Keeping the existing stuff going and adapting it to changes like new data formats or new Windows versions often enough eats up most of the time.

 

Requests like yours only have a good chance, if they can get implemented easily, because they fit into existing structures and only require few additional or changed lines of code. Or, of course, if many users want it.

 

Nevertheless I will keep an eye on it, and if I see a chance to integrate text output for radio text (besides OSD graphics, as it is now), I will try... however, there is still one open question from my side:

 

On 6/19/2021 at 6:41 AM, Griga said:

Which channels offering radio text do you receive? The only ones I know are German and Swiss channels via satellite.

 

Anyway, thanks for input and feedback!

 

Posted

Astra 19.2 is what we all have access to.

further.: Astra 23.5, all these small  polish packages from 11674-11683 pol. V with feeds for RMF and Agora radio group. also astra 23.5, 12639 V sr 940 (DLF feed to the transmitters), 12646 SR 285 (NRW lokalradio feed for local studios)

 

Also the DVB-IP package of Polish Radio at 7.0E, 12633 sr 1302 after loads and loads of playing around.

both the IPTV package of Polish radio from 7E and those small packages from 11674 11675 V on 23.5E contain both classic RadioText as well as Radiotext embedded in aac frames since some polish feeds have converted to aac LC  about a year ago.

 

I am also not sure if swiss package from 13.0E had no RDS, Should check before posting but have no access to the dish at the time.

Also, Hi-Fi versions of stations from 5.0W  (feeds for french broadcasdting centres) I've seen some radiotexts there.

 

Posted
Am 21.6.2021 um 19:50 schrieb Patryk F:

further.: Astra 23.5, all these small  polish packages from 11674-11683 pol. V with feeds for RMF and Agora radio group. also astra 23.5, 12639 V sr 940 (DLF feed to the transmitters), 12646 SR 285 (NRW lokalradio feed for local studios)

 

That's interesting. My dish pointing to Astra 23.5° is too small to receive low symbolrate transponders (just 45 cm), but I can receive 11670 V, SR 6000 with the Polish Grupa Radiowa Time channels, all of them using the LOAS/LATM AAC format. At least one of them (PLUS SES) indicates RSD data in its program map table (PMT) by including an ancillary data descriptor. However, the hex viewer didn't show something looking like text in the audio stream. Anyway, that's a point where I can start investigating RDS in AAC streams.

 

I can't receive 5.0° West and 7.0 East, but the German-speaking swiss radio channels on Hotbird 10971 H definitely transmit radio text, because DVBViewer receives and displays it here.

 

How do you know that the Polish AAC satellite channel contain radio text? DVBViewer doesn't detect and display it.

 

Posted

Actually I know which feeds are directly for transmitters and which not, also, since I am a radio guy one might do some OSINT researches and join bits and pieces of information.

I mainly collect the knowledge from polush branch forums and contacts with tech people at soem stations, also, since i know how the systems worked before conversion to AAC, it is costly to change diametrally how the system works now. Ther must be a way of transporting all the radiotext

P.S.: Eska SES  (service 2000) might also expose RDS when it is playing.

 

It is  unfortunate that You cannot receive those small RMF packages, they might be an interesting case study since RMF uses special receivers before it reaches the transmitter.

so it may look different then.

Also, let's check if this is really text or just stream of bytes in some not so friendly format.

  • 4 weeks later...
Posted
On 6/21/2021 at 7:50 PM, Patryk F said:

both the IPTV package of Polish radio from 7E and those small packages from 11674 11675 V on 23.5E contain both classic RadioText as well as Radiotext embedded in aac frames since some polish feeds have converted to aac LC  about a year ago.

 

A short summary of what I have found out and done in the meantime:

  • RDS in AAC frames is unspecified in the DVB sphere. ETSI TS 101 154 only specifies it for MPEG1/MPEG2 audio (MP2). So RDS in AAC ancillary data is a proprietary solution, if used by broadcasters.
  • The German ARD has already launched the new AAC channels on Astra 19.2° East, 10891 H and 11053 H. Trial operation ends and regular operation begins today. However, the old MP2 channels on 12265 H will be kept until the end of this year.
  • The new AAC channels don't embed RDS in AAC frames, but transmit it in a separate data stream with the stream type "user private data". This is not specified by ETSI either. Nevertheless DVBViewer will support it in the upcoming 7.1.1 release, which means, it will be able to detect, display and include this RDS data in TS recordings. Implementing it only required reactivating old code that was used several years ago for some commercial radio stations that transmitted RDS in a similar way.
  • Unfortunately some of the new ARD (AAC) radio channels dropped RDS, though it is still present in the corresponding MP2 channels. I don't know if it will be picked up until the end of the year. A member of the technical ARD staff told me that RDS via satellite will probably be switched off completely in future, because its main purpose is feeding FM transmitters. Most likely it will die together with FM radio.
  • I have added radio text to the text panel for the visually impaired in the DVBViewer main window. The text appears right below the channel name in a single line, if available (or is there a better place?).
  • As I was dealing with it anyway, I have reworked the text panel content in some respects, fixed bugs and implemented two suggestions from your post in November 2018: The main window text panel is now displayed with black text on white background, not white on black anymore (see 5.). Main window audio is muted if another DVBViewer window gets activated (= gets the input focus), but switched on again as soon as the main window gets the input focus back, without having to close the other window first (see 4.). Additionally the muting can be switched off completely in Options -> Extended with a new checkbox "Mute main window while another DVBViewer window is active".

Maybe you can evaluate the changes after the 7.1.1 release, and we can discuss if there are further enhancements for the visually impaired that can be implemented with reasonable effort.

 

Posted

FIrst of all thank You very much.

After brief but extensive testing it seems that everything works perfect or at least near perfect.

I haven't caught any inconveniences

The first thing I did is disabling the mute at all, then enjoy the RDS.

That's what I thought of.

BTW, two off-topic but related questions.:

1. Is there a way to make the HBBTV content accessible too?

It seems that mmaking it rendered as normal HTML in a separate accessible HBBTV window would be enough.

Currently, when a visually impaired one buys HBBTV addon there is no useful way to use it being blind, since all the content is rendered OSD only as I understand.

2. May we check whether support for RDS contained in the Cesky rozhlas package (aac content) Astra 23.5 12344 mHz is possible?

In their mp2 versions they had RDS but now I am not sure.

Posted
Am 27.7.2021 um 13:04 schrieb Patryk F:

1. Is there a way to make the HBBTV content accessible too?

 

Unfortunately no. HbbTV is handled by third-party components, specifically a browser component and an add-on that makes HbbTV digestible for the browser. DVBViewer passes URLs (originating from the DVB Application Information Table) and keystrokes to this combo and gets in return a bitmap picture of the rendered HbbTV page, which is displayed in the OSD. This means, DVBViewer doesn't get to see the HTML code.

 

Am 27.7.2021 um 13:04 schrieb Patryk F:

2. May we check whether support for RDS contained in the Cesky rozhlas package (aac content) Astra 23.5 12344 mHz is possible?

 

I can see no evidence for RDS there. All channels are broadcasting an LOAS/LATM AAC audio stream and private sections containing an HbbTV Application Information Table (AIT), nothing more. However, HbbTV doesn't show up in DVBViewer for unknown reasons. Regarding the audio stream, I can't see something that looks like text in the hex viewer.

 

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...