Jump to content

Difference source filter DVBviewerPro <--> ALTdvb (H.264)


w8andc

Recommended Posts

My I have your attention, please.

 

I use the following hardware/software:

 

* Technotrend S2-3200 PCI card + CI and latest BDA drivers for satellite reception

* Twinhan DVB-Cab CI PCI card and latest BDA drivers for cable reception

* Processor: AMD Turion 64 ML 44 @2.58 Ghz

* ATI Radeon X1600 Pro AGP - 512 MB videocard

* 1GB RAM DDR 400 Mhz memory

* latest DVBViewer source filter (2.8.2.0)

* using overlay mixer

* Dscaler5 version 0.08 or Nvideo purevideo --> Mpeg2 video decoding

* CoreAVC Pro 1.1.0.5 (09/06/2006) --> AVC/H.264 Mpeg4 video decoding

* AC3Filter 1.11 --> Mpeg audio + AC3 decoding

* Terratec Aureon Space 7.1 audio PCI card using SPDIF to DENON receiver

* MSI k8N Neo Platinum motherboard (nforce 3 250 Gb chipset)

 

First I make clear that HDTV Mpeg2 reception (Astra HD, Euro1080) is very smooth !

No problem at all.

 

H.264 problem:

 

In DVBViewer Pro the reception of HDTV H.264 channels (Astra HD, AnixeHD, BBC HD, Prosieben HD,..) is not 100% smooth.

It seems video stops a few miliseconds each 3 or 4 seconds. Watchable, but very annoying and should to be good more fluent.

I tried almost everything to detect a possible problem or interruption without any solution:

 

* different DVBViewer filters

* different H.264 software decoders

* disabled EPG

* disabled OSD

* disabled CI and even disconnected CI form PCI card

* CPU priority set to Low or High

* no skin

* DVBViewer GE --> no video on H.264 channels at all --> very strange

 

The little, but annoying disturbance, just won't disappear.

Sometimes there are also coloured blocks in the video image. Fault in decoding I suppose.

 

So, I was almost making the conclusion my configuration is not capable for decoding HDTV H.264 fluent enough.

 

Till, some days ago (23/10/2006) the new version of ALTDVB 2.2 was announced on www.dvbmagic.de. The official website (www.altdvb.ro ) doesn't mention this new version at the moment and it is only donwloadable on the DvbMagic website by a hyperling which directs to a subfolder on the official website !

 

I downloaded and installed this program, and tried it with the same configuration!

And guess what?

 

All H.264 channels are very, very smooth and nice!

 

So, there must be something different in the way DVB H.264 TS streams are worked around by AltDVB 2.2 and DVBViewer Pro.

 

Can someone confirm this issue?

Maybe other persons have detected the same issue.

Edited by w8andc
Link to comment

Does the DVBViewer Filter property page display errors? Discontinuities?

 

Same issues with H.264 file playpack?

 

DVBViewer GE --> no video on H.264 channels at all --> very strange

Audio?

 

H.264 is still a kind of gamble :bye: Little timing differences may cause problems in one case, and success in other cases, and the other way round. There are a lot of people who use DVBViewer for watching H.264 live transmissions, and in many cases it works pretty well, provided the hardware is powerful enough, and in other cases it doesn't, though the configuration is similar, for unknown reasons. Individual experience can not be generalized. I think, early adaptors have to live with that...

Link to comment

Hello Griga

 

 

My fault.

 

I cleaned the channellist in DVBViewer GE 2.1.1.0 and did a complete new scan of the Astra 1B,1C,... satellite (19.2°E). The HDTV H.264 channels are now comming in.

But it keeps the same issue: every 3 seconds there is a slide interruption of the signal or freezing of the image in other words!

 

The DVBViewer filter property page doesn't show any errors or discontinuities.

 

Like you asked me I did some testing with H.264 encoded files playing back with DVBViewer GE and Pro.

I tried different types: WMV HD files, TS files, MOV files, MKV files,... in 720p or 1080i and 1080p.

 

And surprise surprise: they all play very smooth in both DVBViewer Pro and DVBViewer GE. Also video and audio are in good synchronisation. NO INTERRUPTION AT ALL ! I believe my system must be powerfull enough though.

 

During my testing one thing , maybe something important , came to the surface: COREAVC Pro activates for H.264 encoded files always AVC1 (big letters). The same happens with AltDVB for live viewing !

 

And guess what?

For live viewing DVBViewer Pro and GE always uses H264 in the settings.

 

Very strange!

I don't know what the difference is between all those different settings in the CoreAVC decoder Pro. It obviously can't be set active manually. This will happen in the background. Only check in or check out one or more setting is possible.

It seems the source filter can influent the settings or behavior of CoreAVC I suppose. And the DVBViewer source filter does this different in comparison with the AltDVB source filter.

The color space output always used is YUY2.

 

Maybe this is something worthwhile to take in research.

 

Let me know !

Edited by w8andc
Link to comment
During my testing one thing , maybe something important , came to the surface: COREAVC Pro activates for H.264 encoded files always AVC1 (big letters). The same happens with AltDVB for files and live viewing !

Very interesting observation. :bye:

 

However, I've just tested it with Luxe TV HD (Hotbird) and BBC HD (Astra 28° East), and always got "H264 Activated", with file and live playback (DVBViewer Filter 2.8.2, CoreAVC Pro 1.1.0.5). Maybe it depends on the broadcasted format? Unfortunately I can't receive DVB-S2 channels yet.

 

There are different levels of H.264, and compared to AVC1, H.264 is the more advanced format. In my opinion, H264 should be the active input - I didn't tell the DVBViewer Filter to connect with AVC1 to the H.264 decoder. If I deactivate H264 on the CoreAVC property page, it doesn't connect to the DVBViewer Filter anymore. Which DVBViewer Filter version was involved? Are you sure that it is CoreAVC 1.0.0.5? Would be a different one than mine.

 

Strange, isn't it? As I said... there are still some mysteries concerning H.264. I think I will try AVC1 as connection format tomorrow, and then we'll see what happens...

Link to comment

Hi

 

Some further information.

 

 

Indeed I use the latest official CoreAVC Pro decoder: 1.1.0.5 (09/06/2006).

I wrote this wrong earlier in my tread and corrected it already.

 

 

When I switch to Luxe TV HD on Hotbird, CoreAVC also uses H264 in DVBViewer Pro and AVC1 in AltDVB. But obvious there is something different because this channel was always the smoothiest channel of all H.264 channels in DVBViewer Pro. Maybe just DVB-S modulation encoded in H.264? In DVBViewer it is not visible if it is an DVB-S or DVB-S2 channel.

 

Indeed, when you capture in DVBViewer Pro a live transmission and playback the recorded file in DVBViewer pro, also H264 will be used as active setting in CoreAVC Pro.

But I tried different earlier downloaded files independed from DVBViewer Pro and when playing those files in DVBViewer Pro AVC1 is used as active setting in CoreAVC Pro.

 

I suppose the fluency of the video image depends on:

 

1) the information in the data stream

2) the correct activation of the active setting in CoreAVC Pro

3) communication between data stream, DVBViewer filter and the software H.264 decoder.

 

Stuttering is probalby not so visible on systems with very much horsepower like dual core systems.

More visible or recognizable on "lower end" systems.

 

I'll hope you can improve DVBViewer Pro with my information.

 

Thanks already for the effort.

Edited by w8andc
Link to comment

Ok, I tried AVC1 FOURCC as connection format, and the CoreACVC accepts it quite happily, but I can see no difference (compared to H264 FourCC as connection format, which IMO is the correct one).

 

Nevertheless, in the members area, beta section, you'll find a DVBViewer Filter test version with a hidden option. Close DVBViewer, open the file DVBSource.ini with a text editor, add the line

 

UseAVC1=1

 

to the [Params] section and save it. After that, CoreAVC should display AVC1 as active format.

 

Please note that it may depend on the user mode where the actually used DVBSource.ini is located. Read more about it here.

 

BTW: Did you already try to disable deblocking and/or deinterlacing on the CoreAVC's property page? Maybe the decoder does it automatically if AVC1 is the connection format, dunno...

Link to comment

Dear Griga,

 

 

First thank you very much for your effort !

I appreciate this.

 

I replaced the old filter by the suplied test filter 2.8.3.1 and changed the correct DVBViewer.ini file.

Started DVBViewer Pro, checked if the correct filter is used, tuned to H.264 channels.

 

Sorry, unfortunally I have to tell you that the same problem stays!

The CoreAVC decoder now activates AVC1 indeed! So that is changed.

 

Stuttering is most visible when the image shows camera movements from left to right or bottom to top or otherwise and zooming in or out. On ASTRA HD on a sudden moment you can see a close up of fireworks. In this part it also is good recogonizable.

 

I tried of course also to disable deblocking and/or deinterlacing on the CoreAVC's property page before and now. But no difference.

 

I checked again the behavior in AltDVB and there is no disturbace at all. Very smooth image without stuttering. The image quality seems not to be less than in DVBViewer Pro.

 

So, there must be some other difference between DVBViewer and AltDVB. I only can see what I see in the surface. The background is for source code people :-)

Maybe a (tricky?) proposal: you can contact the maker of AltDVB. If not direct maybe by dvbmagic because they must have contacts with the programmer. It seems altxro is the one in the ALT DVB section of the DVBN forum .

 

I"ll still hope the image will be even smooth in DVBViewer as in AltDVB.

 

Thanks again.

Link to comment

I've checked everything.

 

I can confirm that I used the same configuration hardware + software settings for both DVBViewer and AltDVB.

Overlay mixer, CoreAVC, AC3Filter and resp. DVBViewer test filter 2.8.3.1 or AltDVB source filter.

Edited by w8andc
Link to comment

Hi,

 

Two remarks:

 

1) The only application that I know of that makes a slight difference between the FourCC AVC1 and H264 is mplayer (from their documentation: AVC1 is H.264 without a syncword in .mp4). I don't know too much about this topic, though... feel free to correct :bye: Moreover, I remember having read that AVC1 is considered the "official" FourCC used in MPEG-container file formats, whereas H264 might be present in other context (dunno is TS is considered in DVB-context a MPEG-container in the previous sense)? But the two raw streams are nevertheless technically the same?

 

2) Also my setup is "on the edge" (i.e. powerful enough +- epsilon) in what comes to playback of H.264 content in DVB-S and DVB-S2 streams. What I have noticed, however, is that file playback may be much more fluent than playback of live stream with DVBV. To be more precise, using timeshift with a small pause and resume (or simply record video and open it with DVBV or by another application) results usually in a more fluent picture (with live playback the number of queued video buffers is something like 10 in my case). Don't know why, though.

 

Cheers,

emmel

Edited by emmel
Link to comment

Ok, in the meantime something came to my mind, that may be worth testing. First I have to do some other work, but I'll come back to it later in the evening, and then I'll do do some researches and a bit of coding. I'll let you know... so stay tuned. :bye:

Link to comment

Again members area, beta section -> GE H264 Test.

 

It's a modified DVBViewer GE 2.1.2 test version, that uses a different COM concurrency model - all DirectShow filters and filter graphs are COM objects, and we have two concurring filter graphs in case of a BDA device. I've replaced COINIT_APARTMENTTHREADED by COINIT_MULTITHREADED. MS says the latter is more efficient. Additionally I've included the COINIT_SPEED_OVER_MEMORY flag. See here:

 

http://msdn.microsoft.com/library/default....d4e88b487f4.asp

 

For activating the new mode, launch DVBViewer GE with the -u commandline parameter. There is one (known) drawback resulting from the multithreaded model (the reason why I didn't use it up to now): View -> Desktop TV doesn't work anymore.

 

So give it a try and see whether MS tells the truth... here I see no difference, except Desktop TV. :bye:

Link to comment

Thank you again for your time!

 

I've tested the modifieded DVBViewer GE test version extensively.

Starting up with the parameter -u like you told. Desktop TV is greyed out when starting with this parameter. So the start up is OK I suppose. Otherwise without this parameter "desktop TV" is possible to choose.

 

Tested with the most recent test filter 2.8.3.1 and also with filter 2.8.2.0.

Again in all cases using Overlay mixer and CoreAVC decoder (deblocking off and deinterlacing off).

 

Sorry. But also in this case unfortunally no difference in behaviour.

The little gaps (stuttering) still are there in the real "H.264 HDTV" channels.

 

So I was thinking again if there is a difference in the background.

 

Something came up!

I am almost forced to say it isn't a H.264 problem, but a modulation (format) problem !

 

I refer to what you told:

 

However, I've just tested it with Luxe TV HD (Hotbird) and BBC HD (Astra 28° East), and always got "H264 Activated", with file and live playback (DVBViewer Filter 2.8.2, CoreAVC Pro 1.1.0.5). Maybe it depends on the broadcasted format? Unfortunately I can't receive DVB-S2 channels yet.

 

It becomes very clear to me that those 2 channels Luxe TV HD (Hotbird - 12322 H) and BBC HD (Astra 28°E - 10847 V) are using DVB-S modulation and containing a AVC/H.264 encoded stream instead of Mpeg2.

Those channels doesn't suffer from the little gaps in DVBViewer and the fluency of the image is almost the same in comparison with ALTdvb! BBC HD should be Europe' s most CPU stressing HDTV channel like I've read. So I understand if this channel can be received in a good quality it must be possible to receive all other H.264 channels in a same way. Not?

 

DVB-S2 channels like Astra HD, AnixeHD, Prosieben HD, ... have those stuttering in DVBViewer. Not in ALTdvb !

So is it possible that DVB-S2 channels are treated different in DVBViewer in comparison with ALTdvb?

I think the problem and solution has to be found somewhere there.

 

Correct me if I am wrong.

 

I should say I will lent me my Technotrend S2-3200 PCI card.

But you are not from Belgium I suppose. Those cards are still hard to get I suppose. It is essential to have compatible hardware to test DVB-S2.

Edited by w8andc
Link to comment
So is it possible that DVB-S2 channels are treated different in DVBViewer in comparison with ALTdvb?

no, this not possible. It makes no difference whether the multiplex is coming from a dvb-s or a dvb-s2 demodulator. Though different drivers for different hardware could have different buffer strategies, but that is only noticeable if you stream a very low rate service like radio.

 

If what you described is true and can be reproduced, there must be other reasons (I'm not the expert for M$ directshow :bye: )

Link to comment

I have another observation:

 

 

If I choose in de DirextX options in DVBViewer "Unchanged" as video renderer and I do the same in ALTdvb. The option "video renderer" (not VMR7 and not VMR9) in ALTdvb seems me the same as the "unchanged" option in DVBViewer.

 

The video renderer values are than visible. When using Overlay mixer this is not visible.

 

It seems in ALTdvb the frames in rederer, jitter, average sync-offset, deviation sync-offset are very close to zero 0 and the average frames played are very close to 25 fps.

 

In DVBViewer the average frames played are also close to 25fps, but all other values grows very much depending on the channel and are further away from zero.

 

I tested this for Luxe TV HD and would send some screenshots with this information in attachment, but I don't have free space doing this.

 

Maybe this is also something to take attention to.

Edited by w8andc
Link to comment
Sorry. But also in this case unfortunally no difference in behaviour.

Well, I always wanted to know whether COINIT_MULTITHREADED does something significant or not. Now I do. ;)

 

Other things I'd try if I had these issues here:

 

- Change the streaming thread priority.

 

If you open the Setup.ini (GE) with a text editior and scroll down to the [hardware] section, you will see that there is a thread priority value (priority.x=...) assigned to each device, with the following meaning:

 

-2 = idle (thread gets only executed if there is nothing else to do)

-1 = below normal

0 = normal

1 = above normal (default)

2 = high

 

The streaming thread is the most important one in DVBViewer. In case of BDA, it is created by the data source (the device driver wrapper, KSProxy.ax, appearing as Tuner or Capture Filter in the BDA graph). This thread passes the TS packets on to various instances within DVBViewer, like playback, EPG, recorder... e.g. decreasing the priority to 0 would increase the relative priority of the threads that are busy with playback (usually two, one for video, one for audio), or with other words, they can't be interrupted so easily by the streaming thread. I suppose there are always enough video buffers queued in the DVBViewer Filter, so the problem may be that the video thread sometimes isn't able to do its job in time.

 

- Change DVBViewer filter settings.

 

The ReadMe that is included in the DVBViewer Filter package (members area -> plugins) describes the meaning of the settings. Particularly "Latency" has some influence on the DirectShow timing. Lowering it means the decoders get data earlier, or with other words, less buffering in the DVBViewer Filter. The default value is tailored quite conservatively (and empirically) for MPEG2 playback. However, for H.264 a different value may be more appropriate. Personally I use 0 ms, resulting in very fast channel switching, but in other cases it may let playback become unstable... dunno. Please note that View -> Rebuild Playback is necessary for a change to take effect.

 

There's still a lot to explore concerning H.264. When I remember how long it took to get everything well balanced with MPEG2... two years, I'd say. :)

Link to comment

Thanks again.

 

It's making me nuts.

 

- Change the streaming thread priority seems nothing to change in the behavior.

 

- Change the DVBViewer filter settings: I tried to set latency to zero, but also no difference in solving the stuttering.

 

I will try some combinations.

 

The maker of ALTdvb must have done some magic tricks I suppose.

Link to comment

I just tested AltDVB, went through all settings and parameters I could find, and got actually the opposite result - the picture is either not so smooth, or slowly loses lip sync with audio (in some cases lots of queued video frames, and it almost looks like the decoder operates with the source in pull-mode... probably I'm wrong here, but it really looks like that). Maybe the behaviour is so hardware dependent after all, that it is difficult draw conclusions.

 

In my case, DVBViewer GE gives the best results. The playback is close to perfect, if I increse the latency from 350 to 500..750 millisecs.

 

Cheers.

Link to comment

Really amazing !

 

I use the Techotrend S2-3200 wiht latest official BDA drivers and the image in ALTdvb 2.2 is (believe me) very good!

 

So, indeed conclusions can only be drawn if more or less the same configuration and hardware is used.

 

There should be at least one other person with more or less the same configuration as mine who can compare the behavior in DVBViewer and ALTdvb on DVB-S2 HDTV channels.

Edited by w8andc
Link to comment

Do you happen to have signalmeter enabled in DVBViewer statusbar? I read in a other forum that the Techotrend S2-3200 bda driver uses the cpu when signalmeter enabled.

And for me it helped to switch of signalmeter!

 

performance on Astra HD (Edit: Corrected text in the picture!)

post-9114-1162726515_thumb.jpg

Edited by kookoo
Link to comment

In the DVBN-forum the maker of ALTdvb gives the following warning:

 

If you are using Technotrend S2-3200 change signal update

interval to 10000 (10 seconds).There is a bug in TT BDA driver

and reading signal status eats a lot of processor

 

The image also demonstrates a hugh difference in CPU loading !

It's indeed worthwile to try.

But can someone tell me how to enable/disable the signalmeter in DVBViewer?

 

Thanks

Link to comment

Simply click on it resp. switch over to the duration / remaining time display. After that, DVBViewer will not query the driver for the signal quality once per second anymore - at least DVBViewer GE doesn't, I've just checked the code.

Link to comment

Jupp, i realized that after the card was running here and changed the signal meter code - which is in my eyes absolutely senseless since all devices have their own values of signal power and i honestly wonder why i ever integrated it in the first time :(

 

Christian

PS: I'm not sure why you seem to have performance differences, but i bet its the buffer which feeds the decoder..

Link to comment
the signal meter code - which is in my eyes absolutely senseless ... and i honestly wonder why i ever integrated it in the first time
:(

 

...IMHO the first use of it is to visualize the presence of the signal (e.g. to catch out signal/DiSEqC problems) and the second is to help in pointing the dish (if it isn't too far from PC)...

...I know and agree that is useless to compare the signal between different cards or different PC (and/or different driver set), but the two previous reason aren't useless...

 

Please don't remove it!

 

:)

Link to comment

..it can't be a reason to abolish the indicators just because it's too difficult to implement a useful indicator. All indicators for tv_pc_applications I know can be described as something between poor and absolutely useless. STBs have identical frontends but there it can be done surprisingly :(

Link to comment
@w8andc: Does switching off the signal quality display solve your problem?

 

 

Very good question, Griga !

 

 

Honestly I don't see much difference in CPU loading on my system when turning off the signalmeter.

Surely not so much decrease in loading as the picture above from KOOKOO.

 

Again there is no change in behavior when using CoreAVC decoder! Little stuttering still exists. So unfortunally problem is not solved.

 

So I tried again the cyberlink H.264 (PowerDVD 7) decoder.

Here the image is completey fluent on the real DVB-S2 H.264 channels (Astra HD, AnixeHD,...) in DVBViewer Pro, but on BBC HD there are too few frames showing.

 

Using the cyberlink decoder the buffers (video/audio) in DVBViewer Pro are close to zero (adjusting the latency values) for those DVB-S2 channels. By using the CoreAVC decoder the buffers grows strong to 300 or more whatever I choose as value for latency. This is another observation.

 

So it seems that I should use cyberlink for DVB-S2 H.264 channels and coreAVC for DVB-S H.264 channels.

Edited by w8andc
Link to comment

Cyberlink uses an internal buffering scheme. BBC_HD is one of the most demanding streams (if not "the").

 

So it seems that I should use cyberlink for DVB-S2 H.264 channels and coreAVC for DVB-S H.264 channels.

..to me that makes no sense :(

Link to comment

Indeed, it makes no sense to me either. But I only can detect !

 

That's why I started this posting.

 

I'm not a newbie. So I should know what I am doing.

 

CoreAVC should be the most efficient H.264 software decoder at the moment.

 

The question still remains: why do I have astonishing fluent image in ALTdvb using CoreAVC decoder for ALL channels and in DVBViewer Pro only for those DVB-S H.264 channels as BBC HD and Luxe TV HD? Considering that I use the same system (hardware) and same software decoder settings!

Edited by w8andc
Link to comment
using CoreAVC decoder for ALL channels and in DVBViewer Pro only for those DVB-S H.264 channels as BBC HD and Luxe TV HD?

How is the performance of these 2 channels in dvb-s2 ?

Link to comment

When scanning ASTRA2 in DVBViewer Pro 4 BBC HD channels are detected. Don't know the frequency (transponder) through my head at the moment.

Two of them having the name BBC HD, the other just the SID I suppose.

In the channellist of DVBViewer Pro it is not shown if it is a DVB-S or DVB-S2 channel if I can remember.

The last ones are the DVB-S2 H.264 channels I suppsose or am I wrong?

 

I tried also those channels and they seemed all OK (fluent image - no little stuttering).

 

I can try it again when I'm home within 2 hours.

Not possible now to test again.

Edited by w8andc
Link to comment
In the channellist of DVBViewer Pro it is not shown if it is a DVB-S or DVB-S2 channel if I can remember.

The last ones are the DVB-S2 H.264 channels I suppsose or am I wrong?

no, it is one and the same service. The DVBViewer stores the different audio channels as different programs. In other applications like altdvb it is only one channel with different audio tracks.

 

Cos you didn't know the difference, my little trick couldn´t work. :) BBC_HD (and the other prgram) is only available in dvb-s. It's not possible to tell how the performance would be with dvb-s2. There ist a lot of imagination and voodoo. We have to stick to the facts ! :(

Link to comment
Cos you didn't know the difference, my little trick couldn´t work. :(

 

No, I can't follow anymore. What am I missing?

Your question was "How is the performance of these 2 channels in dvb-s2 ?". Maybe Luxe TV HD has a DVB-S2 frequency?

Don't matter. :-)

 

BBC_HD (and the other prgram) is only available in dvb-s.

 

That's what I supposed !

 

Hopefully soon a new version of the CoreAVC decoder will be published which will hopefully improve image quality and overall stability and maybe introduce hardware accelaration for ATI / Nvidia.

It's very quiet on the site of CoreAVC: someone maybe news from that front?

Edited by w8andc
Link to comment
It's very quiet on the site of CoreAVC: someone maybe news from that front?

 

CoreAVC 1.2.0.0

 

Unfortunately no GPU acc. in the upcoming version. Will be released in the next hours/days, not more I suppose, was scheduled for Nov. 2nd already..

Edited by CiNcH
Link to comment
  • 2 weeks later...

I've check yesterday, and also found, that CoreAVC doesn't work good on my maschine (Core 2 Duo E6400, ATI X1300, 1.5Gb, P965T-A, S2-3200). Same problem - not smooth motion. Inside AltDVB have grath failure with CoreAVC, so can not compeete. Didn't have too much time for testing.

Link to comment

In the first place I'm happy to hear also other persons can detect the difference. Using the newest CoreAVC decoder 1.2 I can't recognize any improvement in DVBViewer Pro concerning the stuttering on H.264 channels. In ALTdvb 2.2 the image from H.264 channels is very smooth. No stuttering at all !

 

So, I'm convinced there must be maybe a little, but sure an important difference in the filter or other component between both DVB software viewers.

 

I'm also sure the DVBViewer devellopers will find a solution for this issue because I love DVBViewer (OSD, CAM, Recording, ....) Many options you can't find in ALTdvb.

Link to comment

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