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

[tourettes]

red5goahead, again a new .ax. It now waits until at least 10% of the buffer is rendered on device side before even trying to request a new buffer to be filled. Hopefully you dont mind the testing of huge amount of binaries

 

[Henkie Flits]

I'm gonna test the file with Owlsroost file and will report there. Just watched another documentary, here is the data. Do you still would like these things to be posted or only when bugs appear?

IGNORE RESULTS BELOW: I accidently had selected the Default DirectSound audio renderer

General
Complete name                    : E:\TV-Series\Lost.Land.of.the.Jaguar\Lost.Land.of.the.Jaguar.S01E02.2008.BBC-HD.1080p.H.264.AC3.5.1.mkv
Format                           : Matroska
File size                        : 6.66 GiB
Duration                         : 58mn 15s
Overall bit rate                 : 16.4 Mbps
Encoded date                     : UTC 2008-08-07 20:02:32
Writing application              : gdsmux
Writing library                  : Haali DirectShow Matroska Muxer 1.8.122.18

Video
ID                               : 1
Format                           : AVC
Format/Info                      : Advanced Video Codec
Format profile                   : High@L4.0
Format settings, CABAC           : Yes
Format settings, ReFrames        : 2 frames
Format settings, GOP             : M=3, N=12
Muxing mode                      : Container profile=Unknown@4.0
Codec ID                         : V_MPEG4/ISO/AVC
Duration                         : 58mn 15s
Bit rate                         : 15.7 Mbps
Width                            : 1 440 pixels
Height                           : 1 080 pixels
Display aspect ratio             : 16:9
Original display aspect ratio    : 16:9
Frame rate                       : 25.000 fps
Color space                      : YUV
Chroma subsampling               : 4:2:0
Bit depth                        : 8 bits
Scan type                        : MBAFF
Bits/(Pixel*Frame)               : 0.403
Stream size                      : 6.37 GiB (96%)
Title                            : BBC-HD H.264 1440x1080
Language                         : English

Audio
ID                               : 2
Format                           : AC-3
Format/Info                      : Audio Coding 3
Mode extension                   : CM (complete main)
Codec ID                         : A_AC3
Duration                         : 58mn 15s
Bit rate mode                    : Constant
Bit rate                         : 384 Kbps
Channel(s)                       : 6 channels
Channel positions                : Front: L C R, Side: L R, LFE
Sampling rate                    : 48.0 KHz
Bit depth                        : 16 bits
Video delay                      : -73ms
Stream size                      : 160 MiB (2%)
Title                            : English AC3 5.1
Language                         : English

 

[tourettes]

I'm gonna test the file with Owlsroost file and will report there. Just watched another documentary, here is the data. Do you still would like these things to be posted or only when bugs appear?

I think it is now enough for you to report when something goes wrong. And maybe we need Owlsroost to fix that one issue, since it most likely would cause few other files to fail as well.

 

[red5goahead]

red5goahead, again a new .ax. It now waits until at least 10% of the buffer is rendered on device side before even trying to request a new buffer to be filled. Hopefully you dont mind the testing of huge amount of binaries

Good but not an huge improve . I attach the log.
Less messages than last better result

 

[red5goahead]

I'm gonna test the file with Owlsroost file and will report there. Just watched another documentary, here is the data. Do you still would like these things to be posted or only when bugs appear?

IGNORE RESULTS BELOW: I accidently had selected the Default DirectSound audio renderer

Henkie Flits, I don't understand but Are you playing 24 Fps video on 60 HZ monitor?

 

[tourettes]

red5goahead, again a new .ax. It now waits until at least 10% of the buffer is rendered on device side before even trying to request a new buffer to be filled. Hopefully you dont mind the testing of huge amount of binaries

Good but not an huge improve . I attach the log.
Less messages than last better result

Could you check with 25 and 50 ms values? Since now the timing is so thigh that sleeping might not help at all since we are getting sub milli second area (3 ms / 10 is zero ms when converted to the integers )

I really think that I should move on to the poll / event driven mode. Althou at least Vista64 users aren't happy, unless MS has fixed the flaw in the post-RTM code. I guess they have. If the 25 / 50 ms aren't providing any better results with the latest binary I think there is not much to do other than either try to play around more precis delays (using reference clock instead of the sleep or implementing the event driven WASAPI Exlcusice mode)

 

[tourettes]

Henkie Flits, I don't understand but Are you playing 24 Fps video on 60 HZ monitor?

I guess he's using refresh rate changer. The detected refresh rate seems to be ok.

 

[Henkie Flits]

Correct: the refresh rate changer works really good as far I can see so I continue to use it. It works very easy.

 

[red5goahead]

red5goahead, again a new .ax. It now waits until at least 10% of the buffer is rendered on device side before even trying to request a new buffer to be filled. Hopefully you dont mind the testing of huge amount of binaries

Good but not an huge improve . I attach the log.
Less messages than last better result

Could you check with 25 and 50 ms values? Since now the timing is so thigh that sleeping might not help at all since we are getting sub milli second area (3 ms / 10 is zero ms when converted to the integers )

I really think that I should move on to the poll / event driven mode. Althou at least Vista64 users aren't happy, unless MS has fixed the flaw in the post-RTM code. I guess they have. If the 25 / 50 ms aren't providing any better results with the latest binary I think there is not much to do other than either try to play around more precis delays (using reference clock instead of the sleep or implementing the event driven WASAPI Exlcusice mode)

I attach the log. Result not good. Better for 25 ms.

 

[tourettes]

I attach the log. Result not good. Better for 25 ms.

Log shows much less issues with the 50 ms?