QuickTime was always way ahead of the game in terms of playing videos with a fantastic user interface. They kept innovating the UI so that it would get out of your way while still letting you do the basic things people need to do to watch a video. Even today I feel like QT is one of Apple's non-failures. The only thing I don't like about it is that you can't easily rewind a few seconds backwards. It requires a really steady hand to make sure you don't jump too far back.
There is a technical reason for this, and it's not a QT program problem, but rather a QT container problem. The QT container file does a horrendous job at synchronizing audio and visual streams. QT playback software exploits this problem, though, by intentionally lagging the start of a video by a few frames in order for the audio and visual streams to match up on the timeline. By not having to track the sync after the initial playback lag, the file plays more "reliably" and "quickly" but this also means that the decoder has no reference point from which it can scrub backwards. Because the "quick" in QuickTime really is a misnomer. This is lazy time, not quick time.
That's not true at all. QuickTime container can represent each frame timestamp exactly, and it has got some advanced features like edit lists. Every frame has got a start and stop time, and each sync sample is marked as such, it's even possible to mark on which sample each sample depends. In Matroska for example the stop time is so unreliable you often have to analyse the frame content or wait for the next frame to know the duration of a sample, and who knows if the sync flag is true or not.
You are probably referring to the delay introduced by b-frames, but the mov container has got a atom ('cslg') to store the max and min offsets and put everything in sync again.
Unfortunately third party mov demuxers don't support cslg or edit lists, so they only supports the simplest mov files.
No, I am referring to the delay introduced by compressed audio streams within QT container files. The issue I refer to does not seem to occur for lossless audio. In these situations, the cslg atom, among others, allow the QT format to reliably copy edited stream data without re-writing to the container file.
AAC, like MP3, introduces a padding of silence at the beginning of the stream. Because modern QT container files do not compensate for this, all audio and video streams within this type of QT file will be off sync by default. QT playback software waits for the audio stream to begin (waits for silence padding to end) before video playback begins, even though the streams themselves line up 1:1 in the container file. This is lazy engineering, not an advanced feature.
QuickTime on OSX has a nice feature to quickly move forwards and backwards when watching a video--just swipe horizontally with two fingers to the left or right. It's a little flaky at times, but works for the most part.
It definitely is now. Quicktime was always pretty bad. iTunes worked well in comparison to its contemporaries when it came out which is why the iPod did so well initially (before Apple had a music store). Safari on Windows was always awful and was discontinued without notice leaving users insecure without knowing it.
