DVBViewer 5.3.0 Pro Error upon startup

[majstang]

After install/upgrade from 5.2.9 to 5.3.0 I get a DVBViewer Pro Error message upon each startup.

 

 

---------------------------

DVBViewer Pro Error

---------------------------

Cannot render Mediafile/Output Pin, error: 0x80040200 En

ogiltig medietyp angavs.

---------------------------

OK

---------------------------

 

Seems it is related to something in the DVBViewer filter. Doesn't matter if using EVR or custom renderer, same error when switching in options/directX. DVBViewer starts up and works fine after pressing ok button, but audio doesn't work.

Edited April 27, 2014 by majstang

[Griga]

Audio type? Options -> DirectX audio settings for this type? Bitstream output?

[majstang]

Audio type? Options -> DirectX audio settings for this type? Bitstream output?

 

Audio type = MPEG Audio stereo 48kHz, 256kbps

Option/DirectX MP2 Audio decoder = Cyberlink Audio decoder (PDVD11)

Audio renderer = Directsound HDMI AMD

Bitstream output = No, I think it is PCM

 

Downgraded to DVBV 5.2.9 and everythings back in working order.

[HenPen]

Got same error and no sound. But after changing Audio Track to AC3 the audio worked.

[lysergic]

I get the error on all channels that use AC3, I'm using LAV for all formats.

[Griga]

Pre-release tests didn't reveal this problem. Will be checked again...

[Griga]

@vramor: Off topic post moved.

 

@Others: I think the error message shows up because DVBViewer Pro 5.3.0 strictly insists that the decoder configured on Options -> DirectX must be used. Specifically the audio decoder in this case. We changed it because Windows sometimes tends to override the user settings for unknown reasons.

 

However, If the audio decoder cannot connect to the audio renderer selected on Options -> DirectX, you will get the error message. E.g. if the audio decoder is configured for bitstream output (SPDIF, HDMI), but the audio renderer can't process it. Or the other way round.

 

Audio renderer = Directsound HDMI AMD

Bitstream output = No, I think it is PCM

 

DirectSound HDMI is bitstream!

 

So I guess DVBViewer Pro 5,2,9 just used another decoder in this case and ignored the one configured on Options -> DirectX for the audio type. Please have a look at View -> Filters (in 5.2.9) and check if my assumption is true.

[lysergic]

OK, I switched to Microsoft DTV-DVD Audio Decoder for AC3 option and that works ok. The sound quality isn't as good as with LAV so would be nice if you guys could come up with a fix.

 

Thanks for the info.

[Griga]

The sound quality isn't as good as with LAV so would be nice if you guys could come up with a fix.

 

I doubt that the LAV Audio Decoder has been used in your 5.2.9. Without knowing the exact reason resp. getting more feedback here it can't be fixed.

[majstang]

So I guess DVBViewer Pro 5,2,9 just used another decoder in this case and ignored the one configured on Options -> DirectX for the audio type. Please have a look at View -> Filters (in 5.2.9) and check if my assumption is true.

 

Yes, your assumption is correct! Checking View/filters yields that Windows has overridden the Cyberlink audio decoder and uses the default Microsoft DTV-DVD Audio decoder in 5.2.9. Hmm...strange! Never noticed this before. Must figure out why the Cyberlink audio decoder has been ruled out.

[Griga]

Ok, that raises the question is what to do with it: Let playback fail like DVBViewer Pro 5.3.0 (and DVBViewer GE) does, making obvious that something doesn't work as intended, or silently try to work around the problem like previous DVBViewer Pro versions did?

 

I think it is possible to let DVBViewer first strictly insist that the decoder configured on Options -> DirectX must be used, but if this fails, let DVBViewer fall back to the previous method (I still have to try and test it, though). The difference is caused by the usage of ConnectDirect versus Render resp. Intelligent Connect giving the DirectShow mechanisms more influence on what happens, which may be good (because it overrides non-working user settings) or bad (because it may also override working user settings due to "cached" filters or other MS preferences).

[majstang]

First, I have to admit that I never understood the actual problem with MS overrides DVBViewer user settings. It never caused any problems for me in the past. Which improvements will the new method bring, besides letting us know that the decoder of choice isnt used by windows?

 

Secondly, if considerable improvements are gained with new method your proposition sounds like a good compromise:

 

 

 

I think it is possible to let DVBViewer first strictly insist that the decoder configured on Options -> DirectX must be used, but if this fails, let DVBViewer fall back to the previous method (I still have to try and test it, though).

 

Thirdly, if the purpose of the new method is only to enforce DVBViewer user settings, I see no point with it, simply because it worked fine before. Im a strong believer keeping all sorts of errormessages to an absolute minimum, which often signifiy good software.

[darky]

Maybe you should give the ac3 filter a try...

Edited May 3, 2014 by darky

[majstang]

It's not a question which decoder to use, but wanting to know what good the new method brings. I don't think Griga explanied that part, at least not so I could understand it

[Griga]

wanting to know what good the new method brings

 

Every now and then we got a report saying that for unknown reasons the selected decoder was replaced by a MS decoder, e.g. for AAC disabling 5.1 output. Usually it wasn't reproducable on other PCs. Just a question of reliability... additionally IFilterGraph.ConnectDirect is faster than the IGraphBuilder.Render method because it doesn't search for suitable filters.

[majstang]

additionally IFilterGraph.ConnectDirect is faster than the IGraphBuilder.Render method because it doesn't search for suitable filters.

 

That is interesting, but what does this mean more practically? Faster startup time for DVBViewer or maybe it even shaves off a second or two on channelswitching time? First impression using 5.3.0 is both seem to be quite more rapid, but havent done any timed comparison with old version though.