1 |
On Sun, 13 May 2012 18:03:59 -0400 |
2 |
Michael Mol <mikemol@×××××.com> wrote: |
3 |
|
4 |
> On Sun, May 13, 2012 at 5:33 PM, Alan McKinnon |
5 |
> <alan.mckinnon@×××××.com> wrote: |
6 |
> > On Sun, 13 May 2012 17:01:07 -0400 |
7 |
> > Michael Mol <mikemol@×××××.com> wrote: |
8 |
> > |
9 |
> >> On Sun, May 13, 2012 at 4:53 PM, Alan McKinnon |
10 |
> >> <alan.mckinnon@×××××.com> wrote: |
11 |
> >> > On Sun, 13 May 2012 14:12:04 -0400 |
12 |
> >> > Michael Mol <mikemol@×××××.com> wrote: |
13 |
> >> > |
14 |
> >> >> On Sun, May 13, 2012 at 4:56 AM, Alan McKinnon |
15 |
> >> >> <alan.mckinnon@×××××.com> wrote: |
16 |
> >> >> > [1] .avi files are notorious for this shit. It's what happens |
17 |
> >> >> > when you are Microsoft and you release any old crappy format |
18 |
> >> >> > without consulting the other experts out there (who will |
19 |
> >> >> > always outnumber you) |
20 |
> >> >> |
21 |
> >> >> Which better container formats were available at the time AVI |
22 |
> >> >> was released (1992)? The only contemporary container format I'm |
23 |
> >> >> aware of is RIFF, which came out in 1988. MPEG-1 didn't come |
24 |
> >> >> out until 1993, which was the same year the Ogg project |
25 |
> >> >> started. Real's stuff didn't come out until 1995. Matroska was |
26 |
> >> >> announced a decade later, in 2005. |
27 |
> >> >> |
28 |
> >> >> Matroska, MP4 and even OGG are nicer container formats, sure, |
29 |
> >> >> but they weren't around yet. And even with any of them, it's |
30 |
> >> >> perfectly possible to accidentally get A/V desync or stuttering |
31 |
> >> >> if you don't mux your streams properly. |
32 |
> >> >> |
33 |
> >> >> (This post draws heavily on Wikipedia for date information, and |
34 |
> >> >> dates may be considered only as accurate as Wikipedia...) |
35 |
> >> >> |
36 |
> >> > |
37 |
> >> > You missed the essence of my post entirely. |
38 |
> >> |
39 |
> >> Anti-Microsoft snark? I thought I was calling you on it. |
40 |
> >> |
41 |
> > |
42 |
> > I said .avi is a crappy format, and it is, that much is obvious to |
43 |
> > anyone who understands the simple basics of what a container should |
44 |
> > do. |
45 |
> |
46 |
> The MPEG group had only been formed four years prior to AVI's release, |
47 |
> and didn't release their first standard until a year later. Meanwhile, |
48 |
> Microsoft needed a video file format that: |
49 |
> |
50 |
> 1) Was a file format that sat on disk |
51 |
> 2) Synchronized audio and video |
52 |
|
53 |
|
54 |
This is the part they got wrong. |
55 |
|
56 |
Would you not agree that this is the second-most important feature |
57 |
required, where the ability to actually play the audio/video at all is |
58 |
the first? |
59 |
|
60 |
Getting that wrong is to me akin to building a car and forgetting to |
61 |
provide it with an adequate means of stopping. There are many other |
62 |
things that can be forgiven where one would need a predictive crystal |
63 |
ball, but needing time sync information in the container is just simply |
64 |
self-evident. |
65 |
|
66 |
|
67 |
|
68 |
|
69 |
> 3) Integrated cleanly with their being-developed operating system (AVI |
70 |
> is very closely related to the Video for Windows API. It's worth |
71 |
> noting that WMF, another Microsoft format from this time, is |
72 |
> essentially a serialized form of their drawing primitives.) |
73 |
> 4) Ran smoothly on an 80386 at 33MHz with a 16-bit, 8MHz data bus |
74 |
> between the CPU and persistent storage. |
75 |
> |
76 |
> With the exception of perhaps (3), those are the "basics." Consider |
77 |
> that this was released in 1992, and then consider that it had probably |
78 |
> been under development for at least a couple years prior. |
79 |
> |
80 |
> I won't disagree that AVI is a crappy format by today's standards, and |
81 |
> that it should be avoided where possible, but what you consider simple |
82 |
> and obvious today was *new* at the time, and so not simple and |
83 |
> obvious. |
84 |
|
85 |
I'm not talking about today's standards. I'm talking about 1992 |
86 |
standards. |
87 |
|
88 |
It's not reasonable to expect MS devs to anticipate algorithms that did |
89 |
not exist then, or hardware that was 10 years away, or even that the |
90 |
internet would be what it is. I do expect devs to get right aspects of |
91 |
their software that will be used right at the time it is released. |
92 |
|
93 |
> |
94 |
> > It would have been obvious to the .avi developers then. And yet it |
95 |
> > somehow made it's way to market and got used extensively |
96 |
> > |
97 |
> > You asked what alternatives were available. That is not a question I |
98 |
> > asked. It matters nothing that the public used .avi so much (they |
99 |
> > had precious little in the way of choice). So whether they had |
100 |
> > alternatives or not is irrelevant. |
101 |
> |
102 |
> It's entirely relevant if you want to consider whether not the |
103 |
> expertise to come up with a 2012-modern format *existed* in the |
104 |
> lead-up time to 1992. |
105 |
|
106 |
Again, I'm not talking about 2012 |
107 |
|
108 |
> |
109 |
> > |
110 |
> > The entire gist of my post was about how .avi as it stands is crappy |
111 |
> > and should never have been released by an entity with the |
112 |
> > engineering clout of Microsoft as they don't have the excuse of |
113 |
> > being one dude in Mom's basement who didn't know better. They |
114 |
> > really should have known better. |
115 |
> |
116 |
> Seriously, why? Why do you think that the entire engineering clout of |
117 |
> a company which hadn't yet taken over the desktop market(!) would be |
118 |
> focused on perfecting AVI, one piece of a large, |
119 |
> already-late-to-market product? They had a bunch of difficult things |
120 |
> to pay attention to, such as mixing protected-mode and real-mode |
121 |
> applications on hardware in a task-switching environment, and working |
122 |
> around compatibility for programs whose developers still assumed they |
123 |
> had full run of the system. On a 386. |
124 |
> |
125 |
|
126 |
No, I expect them to get the basics right. Cars and brakes. |
127 |
|
128 |
-- |
129 |
Alan McKinnnon |
130 |
alan.mckinnon@×××××.com |