Sign In
Register
Help
tokyovigilante, on May 21 2009, 10:07 AM, said:
at 24fps, your computer has ~42 ms to decode each frame, or you will get stutter, and this depends on memory speed, IO bandwidth etc, as well as CPU. I'm not saying you're wrong, or the problem doesn't exist, but it's unlikely to be straightforward. We are looking at it closely though.
I think we all kinda have a concept of how a computer works, thanks for the bandwidth tutorial though...
whats this 24fps... all my movies are 24fps.... and they don't shudder under .13.
Clearly Aaron's reply shows more facts.
Have you actually tested the clips i provided yourself? If not, do.
Also be sure to get the longer clips, they show that the issue happens at low activity (cpu, bitrate, motion)
It sounds like your just putting stuff out there without testing these clips or having any experience with the real issue.
Ive moved them, so you can find them here now: http://digitalbuss.com/HTPC/plex/clips
im moving 2 over now as i write.
Again!!!! ALL these clips play fine on my 2.33c2d MBP with .13. AND DO NOT with .14 and up.
God, you guys look like Ben Affleck (Elan) and Nike Lachey (tokyovigilante)
aaronjb, on May 21 2009, 10:52 AM, said:
The problem in that ticket is definitely more than a CPU bottleneck - the symptoms do lessen on a fast enough machine (for example, it's much less intrustive on my 2.8GHz unibody), but the cause appears to be the repeated failures to decode individual frames, where each failure causes a pause in playback.
[edit] The problem with the VC-1 samples seems to be that occasionally the frame decode returns 0 bytes, which causes the DVDPlayerVideo.cpp to b0rk:
iDecoderState becomes VC_ERROR and triggers this block:
I think it's actually the reset that causes the big stutter (which doesn't register as a dropped frame, because it isn't dropped - it just failed to decode).. but I strongly suspect the root cause is buried somewhere in the m2ts demuxing code, because the same error condition seems to trigger for H264 encoded m2ts video as well, which would imply that the VC-1 decoder is not, in this case, at fault.
[edit edit] Whoops, was using the XBMC code for the above examples, which is slightly different - the Plex code in the problematic area appears almost identical, but is lacking the log message seen above. In Plex it's:
[edit] The problem with the VC-1 samples seems to be that occasionally the frame decode returns 0 bytes, which causes the DVDPlayerVideo.cpp to b0rk:
int iDecoderState = m_pVideoCodec->Decode(pPacket->pData, pPacket->iSize, pPacket->pts);
iDecoderState becomes VC_ERROR and triggers this block:
if (iDecoderState & VC_ERROR)
{
CLog::Log(LOGDEBUG, "CDVDPlayerVideo - video decoder returned error");
m_pVideoCodec->Reset();
break;
}I think it's actually the reset that causes the big stutter (which doesn't register as a dropped frame, because it isn't dropped - it just failed to decode).. but I strongly suspect the root cause is buried somewhere in the m2ts demuxing code, because the same error condition seems to trigger for H264 encoded m2ts video as well, which would imply that the VC-1 decoder is not, in this case, at fault.
[edit edit] Whoops, was using the XBMC code for the above examples, which is slightly different - the Plex code in the problematic area appears almost identical, but is lacking the log message seen above. In Plex it's:
507 // if decoder had an error, tell it to reset to avoid more problems 508 if( iDecoderState & VC_ERROR ) 509 m_pVideoCodec->Reset();
MultiQuote
.
