MediaPortal Audio renderer - better video playback quality (2 Viewers)

[gibman]

Im using the EncodeToAC3 feature.

Is it on purpose that when dealing with 2 channel audio (eg. mp3 track) that it is being encoded into an AC3 2.0 track ?

This way I cant change volume when using my HTPC remote control, since its ac3 spdif.

Why not keep mp3 audio in the mp3 domain when resampling ?
The same goes for ac3 ?

mp3 -> mp3 (resampled)
ac3 -> ac3 (resampled)

/gibman

 

[Seeco]

A quick question - what version of the renderer is incorporated into MP 1.2.0 Alpha? Do I still need to use the files in this thread to have the cutting edge version?

 

[tourettes]

A quick question - what version of the renderer is incorporated into MP 1.2.0 Alpha? Do I still need to use the files in this thread to have the cutting edge version?

Nothing is included in the MP 1.2.0 alpha. Currently the audio renderer's real target is MP2 so it will stay as a separate from the main MP1 releases (at least for now with 1.2.0, probably as well in the future).

 

[Seeco]

OK, I misunderstood the part in the release notes about "smooth video playback". Thanks!

 

[tourettes]

Im using the EncodeToAC3 feature.

Is it on purpose that when dealing with 2 channel audio (eg. mp3 track) that it is being encoded into an AC3 2.0 track ?

This way I cant change volume when using my HTPC remote control, since its ac3 spdif.

Changing volume level on HTPC side should be always banned since it will just ruin the audio quality

Why not keep mp3 audio in the mp3 domain when resampling ?
The same goes for ac3 ?

Since I wont use AC3 and no one has ever nagged about the issue I think there is no reason to encode the mono / stereo audio tracks into AC3 after resampling has been done. It will only slightly lower the audio quality. I'll change this behavior in next release.

mp3 -> mp3 (resampled)
ac3 -> ac3 (resampled)

Actually it would be:

mono or 2 channels -> resampled -> PCM
multichannel -> resampled -> AC3

 

[Owlsroost]

OK, I misunderstood the part in the release notes about "smooth video playback". Thanks!

MP 1.2.0 includes a version of the dshowhelper from this thread (with no audio renderer support) - that's what the "smooth video playback" comment is about

Tony

 

[tourettes]

All problems with ver. 16 AC3 encoding seem to be gone in new version, at least on my hardware.
I also checked new feature - audio delay. I need that for 24Hz so till now I used that option in ffdshow audio decoder.
After watching a movie I must admit that it works good.

Nice to hear that it works. ver 17 has still a slight bug in the delay adjustment. The delay is 10x too big. If registry has 10 ms it will be actually 100 ms - this will be fixed in next release.

Would be great if audio delay could be dependent on source FPS or display Hz. For example: I must set different audio delays for 23-24 Hz and 50 Hz, when for 60 Hz I set no delay.

That would be something for the player to specify (audio renderer doens't know or care about the refresh rate or video fps). So, maybe something for MP2 since MP1 itself wont be changed for the audio renderer (and providing a patched core.dll etc. would be just too big effort - keeping those in sync... also there would be al kinds of weird conflicts / bugs to be solved with the pached dlls...).

 

[tourettes]

I haven't read all the posts, but I decided to try this solution in an attempt to resolve the occasional stuttering. This solution seems to work well to prevent my stuttering issue, but there are a couple of bad side effects. Resuming after pausing results in a period of silence. Lip sync can also go out enough to be annoying, either during pausing or seeking.

I just thought I would mention these issues. I've decided to use an alternative dshowhelper.dll I found on this forum which also appears to resolve my problem without using this renderer.

I would be glad to hear some more details on the lipsync issue - even when you aren't going to use the renderer itself. All help we can get is wanted.

The period of silence after resuming from pause is a known issue and there is currently no way to fix it. It is related to WASAPI buffers, so you could reduce the amount of the DevicePeriod setting in registry. To fix it properly requires a complete refactoring how sample pipeline is handled and it would also require sample caching to be implemented (when pause state is resumed we need to send the already send data to the audio device. Also the whole resampling queue needs to be preserved...). CUrrently the issue is much too small annoyance that it would be worth to fix it (sample pipeline is going to be reworked in the distand future to allow more complex audio processing but that is a different story).

 

[Seeco]

I am currently seeing some stuttering. I have been noticing it for a while, but haven't taken the time to log it until now. The logs are recorded playing a typical HD video, which afaik don't have any special errors in it. I can see no dropped frames, but all the three lines make a big skip (and at the same time I see stutter) once in a while. Any ideas?

 

[tourettes]

I am currently seeing some stuttering. I have been noticing it for a while, but haven't taken the time to log it until now. The logs are recorded playing a typical HD video, which afaik don't have any special errors in it. I can see no dropped frames, but all the three lines make a big skip (and at the same time I see stutter) once in a while. Any ideas?

Logs aren't giving any clues, could you post a screen shot about the rendering stats when the failure occurs? Also check with other than ffdshow DXVA H264 decoder - for example with MS DTV-DVD codec which comes with Windows 7.