DD 1.4b resets DS filters faster than 1.4a crashed DD
Posted: Tue Nov 06, 2007 8:51 pm
Audio buffer blue stripe grows fast no matter what audio filter is used, but DD resets way long before it reaches right-hand limit.
No amount of additional buffer memory for both video and audio changes anything, including frequency of resets (about 0.5....1 Hz, that is about 1... 2 times in a second)
Priority Normal or High -- doesn't matter.
Prevent using second core or not --- doesn't matter either.
Naturally, I talk about HD mpeg4 put through CoreAVC 1.5 or latest Cyberlink (3114a patch I think), as I normally don't watch mpeg2 channels. For which if I occasionally do, DD 1.4 Final is quite perfect.
One addition: in that fraction of a second before resetting, Cyberlink's lipsync lag problem is still there. BTW, no fixed amount of video delay shift (Shift-"-" keystrokes) can sync it forever, or even for a long time. The reason for it is that in PAFF-ignorant Cyberlink the audio lag fluctuates in reality, I guess. CoreAVC must have some post-demuxer PAFF data intercepting code, to be inserted as syncing hooks (or variable shifts while in audio pauses) after its H.264 decoder.
P4 double core 3.3 GHz 2.5 GB RAM MSI RS 2600 HT 256 MB GDDR4 here; building my new C2D E6750 machine right now -- never thought it will come to this, so fast, LOL.
No amount of additional buffer memory for both video and audio changes anything, including frequency of resets (about 0.5....1 Hz, that is about 1... 2 times in a second)
Priority Normal or High -- doesn't matter.
Prevent using second core or not --- doesn't matter either.
Naturally, I talk about HD mpeg4 put through CoreAVC 1.5 or latest Cyberlink (3114a patch I think), as I normally don't watch mpeg2 channels. For which if I occasionally do, DD 1.4 Final is quite perfect.
One addition: in that fraction of a second before resetting, Cyberlink's lipsync lag problem is still there. BTW, no fixed amount of video delay shift (Shift-"-" keystrokes) can sync it forever, or even for a long time. The reason for it is that in PAFF-ignorant Cyberlink the audio lag fluctuates in reality, I guess. CoreAVC must have some post-demuxer PAFF data intercepting code, to be inserted as syncing hooks (or variable shifts while in audio pauses) after its H.264 decoder.
P4 double core 3.3 GHz 2.5 GB RAM MSI RS 2600 HT 256 MB GDDR4 here; building my new C2D E6750 machine right now -- never thought it will come to this, so fast, LOL.