arestarh1986
Member | Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
fil1111
Что нарыл:
раньше x.264 сжимал, как я понял, *по частям*(sliced) и, соответственно, декодирование(для разгрузки процессора) ввели slice-based(как, до недавнего, в ffdshow). Но, потом был введен frame-based encode(x.264) и, естественно, начали *биться* над декодированием(недавнее слияние веток ffdshow + ffdshow-mt). Т.е., если я правильно разобрался и не перепутал *дороги*, multislice file отнести можно к старым ревизиям x.264.
Вот немного вопросов/ответов из Doom9 по этому поводу:
As the title says, thanks to Andreas Oman libavcodec now can make use of dual core processors when decoding h.264
http://svn.mplayerhq.hu/ffmpeg/trunk...=date&view=log
note: depends on having a thread library activated at config time, and on having a source encoded with multiple slices
Q -doesn't x264 not use slices anymore for parallelism?
A - Correct. This patch doesn't work for any stream encoded recently by x264.
A - For those who wish to try it, this functionality is present in ffdshow tryouts since revision 1465.
Q - when (as in revision) was parallel slice-level encoding removed / changed in x264? Can't find it in the changelog.
A - It's actually 607.
Q - In the revision history for ffdshow tryouts, under rev 1463 (5 Sept 2007) it says:
Add slice-based parallel H.264 decoding
Where does encoding come into this?
A - Encoding is important, because the new multi-threaded decoding works only with slices! If the H.264 video was not encoded with slices, the new multi-threaded decoding won't give any speed-up at all! Previously the x264 encoder used slices, but the current revision does not do so any more. Now x264 uses a multi-threading method that works without slices (which is actually better), so the resulting files won't be able to use libavcodec's multi-threaded decoding. At least until they implement a frame-based instead of a slice-based multi-threading method in their H.264 decoder...
If each frame is divided into several slices, each slice can be decoded on it's own. That makes implementing multi-threaded decoding more easy. In case no slices were used to encode the video, you can't use various threads to work on the same frame. So if you want to implement multi-threaded decoding without slices, you will have to find a way to decode multiple frames in a parallel way, so each thread can work on it's own frame. But decoding multiple frames in a parallel way is extremely difficult for various reasons. For example you can't decode a P-Frame before it's reference frame was decoded first. Multiple-reference frames and B-Frames make things even more complex...
A - Yes you can. That's exactly what x264 does. x264's method works for encoding or decoding of any video compression format. Multiref doesn't affect it, and B-frames make it easier. Ok, not quite every format... It wouldn't work with H.264 FMO. But nobody uses FMO. Likewise there might be some complications in Theora because Theora's macroblocks aren't coded in raster order but rather in a hilbert curve.
Q - What's the other method of multi-threaded decoding apart from slices then?
A - The one x264 uses now:
Encode/Decode several frames in parallel.
Ребят, по возможности, хочется услышать и другие версии о multislice file, если данная не верная |
