* adding Michael's explanation to the FAQ
authorRoman Shaposhnik <roman@shaposhnik.org>
Mon, 23 Aug 2004 19:48:41 +0000 (19:48 +0000)
committerRoman Shaposhnik <roman@shaposhnik.org>
Mon, 23 Aug 2004 19:48:41 +0000 (19:48 +0000)
Originally committed as revision 3411 to svn://svn.ffmpeg.org/ffmpeg/trunk

doc/faq.texi

index cf196d9..21c8500 100644 (file)
@@ -14,7 +14,7 @@
 
 ffmpeg development is now concentrated on the codec and format
 handling. New developments broke ffserver, so don't expect it to work
 
 ffmpeg development is now concentrated on the codec and format
 handling. New developments broke ffserver, so don't expect it to work
-correctly. It is planned to fix it ASAP.
+correctly. If you have time and experience, please help us fix it.
 
 @section I cannot read this file although this format seems to be suppored by ffmpeg.
 
 
 @section I cannot read this file although this format seems to be suppored by ffmpeg.
 
@@ -46,6 +46,12 @@ The same system is used for the other image formats.
 No. FFmpeg only supports open source codecs. Windows DLLs are not
 portable, bloated and often slow.
 
 No. FFmpeg only supports open source codecs. Windows DLLs are not
 portable, bloated and often slow.
 
+@section Why do I see a slight quality degradation with multithreaded MPEG* encoding ?
+
+For multithreaded MPEG* encoding, the encoded slices must be independent,
+otherwise thread n would practically have to wait for n-1 to finish, so its
+quite logic that there is a small reduction of quality, this is not a bug
+
 @section How can I read from the standard input or write to the standard output ?
 
 Use @file{-} as filename.
 @section How can I read from the standard input or write to the standard output ?
 
 Use @file{-} as filename.