Originally committed as revision 617 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 616 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 615 to svn://svn.ffmpeg.org/ffmpeg/trunk

  as its functionality is used even in those parts which are being
  compiled without this flag
  - generaly this would require more complicated cleanup patch
  - for now leaving for the main author

Originally committed as revision 614 to svn://svn.ffmpeg.org/ffmpeg/trunk

* fixed busy loop test bug on mmx-only machine

Originally committed as revision 613 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 612 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 611 to svn://svn.ffmpeg.org/ffmpeg/trunk

  (though I'm not sure which one is correct - but they should match)

Originally committed as revision 610 to svn://svn.ffmpeg.org/ffmpeg/trunk

  (how about making all headers in ffmpeg working this way ?)

Originally committed as revision 609 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 608 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 607 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 606 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 605 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 604 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 603 to svn://svn.ffmpeg.org/ffmpeg/trunk

  requests. The current state is that at startup, WMP will get the
  best stream that it can handle. However, subsequent rate switching
  only puts a message in the log saying what the new stream ought to
  be. Solving this will be tricky. I guess that we would have to wait for
  key frames to appear in the new stream, and then switch over to it.
  Some care would be needed to deal with the PTS of the new stream
  versus the old stream.

Originally committed as revision 602 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 601 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 600 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 599 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 598 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 597 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 596 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 595 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 594 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 593 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 592 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 591 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 590 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 589 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 588 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 587 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 586 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 585 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 584 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 583 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 582 to svn://svn.ffmpeg.org/ffmpeg/trunk

a higher priority than extensions. This gives FFM a chance of working. Note
that some of the other probe functions are bit optimistic, and can be
confused by binary data (such as 0x00 0x00 0x01 0xzz) for some values of zz.

This set of changes makes ffserver work again, and fixes the cannot open
video grab device message.

Originally committed as revision 581 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 580 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 579 to svn://svn.ffmpeg.org/ffmpeg/trunk

* Make sure that the read buffer for the ffm file is allocated in the priv_data.

Originally committed as revision 578 to svn://svn.ffmpeg.org/ffmpeg/trunk