| 1 |
On Friday 23 Sep 2011 21:26:56 Nikos Chantziaras wrote: |
| 2 |
> On 09/23/2011 12:54 AM, Mick wrote: |
| 3 |
> > On Thursday 22 Sep 2011 09:15:42 Nikos Chantziaras wrote: |
| 4 |
> >> On 09/22/2011 12:58 AM, Mick wrote: |
| 5 |
> >>> On Wednesday 21 Sep 2011 09:19:39 Sebastian Beßler wrote: |
| 6 |
> >>>>> Does mplayer2 work with smplayer or kmplayer? |
| 7 |
> >>>> |
| 8 |
> >>>> I use mplayer2 with smplayer for a few month now and everything works |
| 9 |
> >>>> just fine for me. |
| 10 |
> >>> |
| 11 |
> >>> Any idea when ffmpeg-mt might make it to the main portage tree? |
| 12 |
> >> |
| 13 |
> >> It's already in the tree. Both ffmpeg as well as libav now have it. |
| 14 |
> > |
| 15 |
> > Sorry I can't see a USE flag or ffmpeg-mt package in portage: |
| 16 |
> > |
| 17 |
> > $ eix -l ffmpeg | grep mt |
| 18 |
> > $ |
| 19 |
> > |
| 20 |
> > or are you saying that the code has been merged in the vanilla ffmpeg and |
| 21 |
> > libav without the need for a USE flag? |
| 22 |
> |
| 23 |
> ffmpeg-mt is not a "package". It's the name of the git branch the code |
| 24 |
> was in. That code was merged into the fmmpeg and libav projects. That |
| 25 |
> means that ffmpeg and libav now do multi-threading. |
| 26 |
|
| 27 |
Yes, I didn't understand this initially. Thanks. :-) |
| 28 |
|
| 29 |
|
| 30 |
> Furthermore, the "threads" USE flag does *not* control this. You get |
| 31 |
> multi-threading regardless of that flag. "threads" only controls |
| 32 |
> another type of multi-threading that was there since a long time now, |
| 33 |
> but doesn't perform well. |
| 34 |
|
| 35 |
Yes, that's how I remembered this, posix compatible threads (pthreads - since |
| 36 |
2004 or so IIRC). |
| 37 |
|
| 38 |
However, my experience with USE=threads which I just switched on to test it, |
| 39 |
is the opposite: |
| 40 |
|
| 41 |
The video rendering in mplayer is sharper and the picture therefore shows |
| 42 |
greater definition. Not much, but enough for me to notice a clearer image. |
| 43 |
|
| 44 |
The impact of threads on the CPU is not noticeable. |
| 45 |
|
| 46 |
|
| 47 |
> It would split decoding of each frame into |
| 48 |
> multiple threads, and the CPU cores would not start decoding again until |
| 49 |
> the whole frame was finished. The speed-up you get by this is minimal. |
| 50 |
> "Real" multithreading, meaning the code from the ffmpeg-mt branch |
| 51 |
> which allows every CPU core to fully decode its own video frame, cannot |
| 52 |
> be controlled by a USE flag. |
| 53 |
> |
| 54 |
> To verify if multi-threading works for you, simply play an h264 video |
| 55 |
> file in mplayer2 (using "-lavdopts threads=N", where N is the number of |
| 56 |
> CPU cores in your system) and use something like "top" or "htop" to |
| 57 |
> check CPU load of each core. |
| 58 |
|
| 59 |
I've removed USE=threads and emerged mplayer2. Multithreading works fine (5 |
| 60 |
threads are shown in top with 4 CPUs and threads=4). However, the quality of |
| 61 |
the video is inferior to vanilla mplayer and USE=threads enabled ... o_O |
| 62 |
-- |
| 63 |
Regards, |
| 64 |
Mick |
Archives