home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Support
Watch / Listen Media
watch/edit Videos
Audio sync problems when screen set to 24 Hz
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Scythe42" data-source="post: 511123" data-attributes="member: 95833"><p>This is the only constant I left in as it is a workaround. If fps information cannot be detected, use 40ms. Therefore it should be safe to use m_rtTimePerFrame as a base for everything. I don't have ts files to test though and all my files provide frame rate information.</p><p></p><p>I thought about this is well like buffering the first second of playback. Probably a value that could adjust itself during playback if too many frames are received late from the mixer. Mixer quality control notifications didn't have any impact in my tests on this. Probably because the filters/codecs don't support notifications themself or don't send them out to the mixer. But not something I'd see happening for 1.1.0 as they are more important issues that need to taken care of to get at least an RC out. I'm a big supporter of stability before new features unless the feature are really enhancing the user experience or a simply overdue compared to other solutions.</p></blockquote><p></p>
[QUOTE="Scythe42, post: 511123, member: 95833"] This is the only constant I left in as it is a workaround. If fps information cannot be detected, use 40ms. Therefore it should be safe to use m_rtTimePerFrame as a base for everything. I don't have ts files to test though and all my files provide frame rate information. I thought about this is well like buffering the first second of playback. Probably a value that could adjust itself during playback if too many frames are received late from the mixer. Mixer quality control notifications didn't have any impact in my tests on this. Probably because the filters/codecs don't support notifications themself or don't send them out to the mixer. But not something I'd see happening for 1.1.0 as they are more important issues that need to taken care of to get at least an RC out. I'm a big supporter of stability before new features unless the feature are really enhancing the user experience or a simply overdue compared to other solutions. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Support
Watch / Listen Media
watch/edit Videos
Audio sync problems when screen set to 24 Hz
Contact us
RSS
Top
Bottom