+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93)
+--- Thread: [WINDOWS][PATCH]Bitstream output of HD audio formats (/showthread.php?tid=121877)
Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
- voip-ninja - 2012-02-18
bluray Wrote:I'm not sure that it is worth mention in here. I tried to playback a newer "Contagion" blu-ray disc on 4 PC's with Intel i3/E7200, AMD APU/X4, Nvidia and HDxxxx GPU's for the last several days. All CPU's/GPU's suffered severe video frames drops and Macroblocking. AMD/Nvidia GPU suffered video frames drops every 7 minutes (5-15 seconds each time), and i3 iGPU got the worst of it because it suffered video frame drops every 30-40 seconds (5-15 seconds each time and it's not watchable). I was able to finish the movie with AMD GPU. What I'm trying to point out here is- it could be blu-ray movie related too. I thought it was a bad blu-ray disc, but it happpened the same way with both Redbox and Netflix discs on the same movie.
My conclusion- i3 suffered the most frame drops when playback "Contagion" using both Daniela/DDDamien XBMC builds and TMT5 as an external player. Since AMD and Nvidia GPU's suffered frame drops every 7 minutes, it was watchable. I don't have the same problem with my other BD's. It was a weird experience to say the least!
My conclusion is that you have DXVA turned on in the i3 setup or you don't have the current drivers. The i3 does not have any more frame drops than the ATI does and it does not have macro blocking with DXVA turned off (and there's no reason to have DXVA turned on since the chipset does not support it and the only benefit of having it turned on is saving about 5 watts of cpu power).
This is getting pretty seriously OT so if you'd like me to quantify these differences for you then we can take the discussion to the appropriate forum.
- meridius - 2012-02-18
DDDamian Wrote:Exactly - pick your processor
Thanks that's good to know as I have a pioneer 5090 and that has an exellent de interlacer.
Cheers
- voip-ninja - 2012-02-19
DDDamian Wrote:@voip-ninja - hate to think we've steered you wrong somehow - can only report what I observe. It may be that my processor is a tad more powerful. I also play with things in my personal builds that simply cannot go into binaries as a matter of policy, such as the thread priorities.
It may be that a solution appears for the TrueHD dropouts you're experiencing and that will allow you to use your preferred video settings.
No worries at all Damian and believe me, I understand you are just making recommendations based on your own observations. I have absolutely no ill will whatsoever, just reporting my results.
- DDDamian - 2012-02-19
apgood Wrote:Might have already been fix further down, but might be some sort of EIDE issue that an eide override might fix (see avs forum thread by tulli).
nikc0069 Wrote:Tried it twice for good measure with different files:
Log 1:
http://pastebin.com/qD0hKMfT
Thx. I can confirm from the log that the correct info is being passed to your audio driver, which then rejects the format:
Code:
21:33:44 T:3432 INFO: CAESinkWASAPI::Initialize: Could not Initialize Exclusive with that format
21:33:44 T:3432 ERROR: CAESinkWASAPI::Initialize: WASAPI initialization failed.You're driver seems to be reporting support in the registry but rejecting it when actually asked if it supports it with the correct information. I would suggest following through on apgood's suggestion above - some receivers suffer from the EIDO bug when handshaking and reporting back their capabilities.
- nikc0069 - 2012-02-19
DDDamian Wrote:Thx. I can confirm from the log that the correct info is being passed to your audio driver, which then rejects the format:
Code:21:33:44 T:3432 INFO: CAESinkWASAPI::Initialize: Could not Initialize Exclusive with that format
21:33:44 T:3432 ERROR: CAESinkWASAPI::Initialize: WASAPI initialization failed.
You're driver seems to be reporting support in the registry but rejecting it when actually asked if it supports it with the correct information. I would suggest following through on apgood's suggestion above - some receivers suffer from the EIDO bug when handshaking and reporting back their capabilities.
THANK YOU!
One happy camper here - used the Samsung LN-S4095D - ONKYO TX-NR906.inf edid override with my Onkyo 309 and it now works Fresh install wasn't necessary but I had a load of rubbish in my movie collection anyway and anything new was on my server.Thanks so much for taking the time to help me out on this one.
- DDDamian - 2012-02-19
nikc0069 Wrote:THANK YOU!
Thanks so much for taking the time to help me out on this one.
Glad you got it - I'll be honest it was asgood's suggestion and good news for others here too!
- nikc0069 - 2012-02-19
DDDamian Wrote:Glad you got it - I'll be honest it was asgood's suggestion and good news for others here too!
Repped you both
This is why I love the XBMC community
Why is this Bitstream not going into standard XBMC? - MichaelAnders - 2012-02-19
I've been wondering on this for ages and now I really have to ask - why is bitstreaming not in the main branch? If it's not 100% operational then that could always be toggled via some XML file so normal users wont experience issues.
I am baffled why I need to download special branches to get this working - I mean why is that needed here? XBMC should do that out of the box
Thanks for any explanations
- Philmatic - 2012-02-19
This is brand new code (few weeks old), which was unfortunately timed badly. Eden is already in the beta stage and it's much too late to add new functionality.
Additionally, AudioEngine will resolve this in the long term, this is a very good, but temporary band-aid until AE is final.
- DDDamian - 2012-02-19
MichaelAnders Wrote:I've been wondering on this for ages and now I really have to ask - why is bitstreaming not in the main branch? If it's not 100% operational then that could always be toggled via some XML file so normal users wont experience issues.
I am baffled why I need to download special branches to get this working - I mean why is that needed here? XBMC should do that out of the box
Thanks for any explanations
The short answer is because it's not done yet. By that I don't mean this build, or any other build, but for the main branch.
XBMC releases on a roughly yearly cycle. It's an opportunity to wrap up changes, release betas for testing, fix any bugs and do a final release. There was a very large re-write of the audio portion planned for this release, but it wasn't ready, especially for OSX, when the feature-freeze was called.
To make the main branch the code needs to be platform-wide, with few exceptions, and also be designed to stay that way. It needs to meet certain requirements and then be peer-reviewed, which often means changes must be made that were not foreseen at the beginning.
What this means is that the core XBMC code still runs on current and target technology, and is both robust and meets the overall criteria for future releases. It means that the code doesn't become haphazard or hamper future initiatives, while still running on all platforms.
Many users want to be on the leading edge of the code developments. Many only care about a specific platform. That's fine, and that's where development like this is welcomed. It's how XBMC evolves.
Users have many options as to how they use/configure XBMC, including making their own modifications and improvements. But the process to get code merged into the master branch is rigorous, as it should be.
Use it, enjoy it, configure it how you will. And when things get added to master and final releases (or even nightlies) you can be assured that they are unlikely to break other platforms or interfere with future development. Until that time you have the benefit of free, open-source software, with the open-source aspect being what got you this build in the first place.
That and some skilled coding
- MichaelAnders - 2012-02-19
Thanks Philmatic and DDDamian, that answers my question
- voip-ninja - 2012-02-19
DDDamian, I have a question about your patch and the timing fix for 24 fps lip sync. What is the playback setting that introduces the delay? I am trying to determine if the delay is still there if I am using 1080p/24 with sync to source but without sync to display set.
Thanks.
- bluray - 2012-02-19
voip-ninja Wrote:My conclusion is that you have DXVA turned on.It's usually turned on, but I tried it with DXVA turned off too.
voip-ninja Wrote:This is getting pretty seriously OT so if you'd like me to quantify these differences for you then we can take the discussion to the appropriate forum.There is nothing to it...I'm not trying to quantify any different. If you haven't follow me closely, I'm often said in general Intel CPU is more powerful than other CPU and I like Intel CPU more than other CPU (as I mentioned, I own i3/E7200 PC's) and I own several i5's at my office. I'm just trying to point out what I found on my PC's after I playbacked "Contagion" blu-ray disc using the latest XBMC patches on all 4 PC's. This is the hardest blu-ray disc to playback on PC for me so far. I thought that XBMC patches, TMT5 and AnyDVD HD would be able to handle it the same way as my other blu-ry disc's, but it is not. AMD/Nvidia discrete GPU's has less troubles than Intel iGPU. I haven't try AMD iGPU (HD6310). I'm thinking that it'll probably be worst than Intel iGPU for this movie!
- bluray - 2012-02-19
MichaelAnders Wrote:I've been wondering on this for ages and now I really have to ask - why is bitstreaming not in the main branch? If it's not 100% operational then that could always be toggled via some XML file so normal users wont experience issues.I'm guessing that they are waiting for Gnif to fully complete/tested AE before they include bitstreaming option in XBMC.
I am baffled why I need to download special branches to get this working - I mean why is that needed here? XBMC should do that out of the box
Thanks for any explanations
- DDDamian - 2012-02-19
voip-ninja Wrote:DDDamian, I have a question about your patch and the timing fix for 24 fps lip sync. What is the playback setting that introduces the delay? I am trying to determine if the delay is still there if I am using 1080p/24 with sync to source but without sync to display set.
Thanks.
That patch is for something much different. Many users see a general overall sync issue, most prevelant on 24p material, but in the realm of 200-250msec. Others experience global delays of ~80msec due to seperate processors for audio vs video, like sending audio via usb and video to HDMI.
That patch is to offset these larger, constant delays, not individual frame-drops. For more on the global AV delay issue see here.