1080i h.264 - xine threads not scaled over more than one cpu cores (maybe BUG?)

hello,

referencing to the changes coming with this fix out of ffmpeg-devel list (H.264 & interlacing 
artifacts: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-July/050391.html) i must 
recognize a significant increase in CPU usage, when receiving HD-material via satellite. 

Especially using ffmpeg (--> xine-lib --with-external-ffmpeg) for decoding HD-live material via 
xine (ex. xineliboutput/vdr) the according processes (xine, vdr-sxfe) do not scale balanced 
between the 2 cpu-cores (2 threads). one core is at 100% now, which was not the case before the 
provider encoder changes (no IDR-/I-frames anymore). Before the change xine/vdr-sxfe scaled even 
over 2 cpu-cores. As a result live HD-channels are jerked now :(

The problem occured with the change in encoding the HD-live stream by tv-providers (especially: 
transponder 11914 on sat astra 19.2E - eg: anixe-hd, astra-hd+, Discovery HD, ..) some weeks ago. 
They do not use IDR- nor I-Frames anymore, but only intra encodete macroblocks (info was 
investigated in appropriate portals).

ffmpeg team then published a fix described in 
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-July/050391.html (H.264 & interlacing 
artifacts). This was the solution for artifacts also described here: "Possible PAFF interlaced 
stream bug(s) fixed in FFMPEG" - http://linuxtv.org/pipermail/vdr/2008-August/017457.html

The application vdr (a linux PVR) uses xine/xine-lib (which was compiled with external ffmpeg 
(svn) support to encode the h.264 live stream). vdr-sxfe is the "frontend" to xine - so it makes 
no difference, when streamed via xine directly or via vdr-sxfe (which is a plugin for vdr).

Tests were also made with mplayer. When a HD-channel out of the named transponder is streamed 
via mplayer directly the cpu-usage is balanced over 2 cores even perfectly. So it seems that 
xine/xine-lib has a problem and not ffmpeg itself (?).

Attached you can find two files - one corresponding to a stream before the provider changed 
their encoding and one after the changes:
 
* 1 minute Discovery 1080i as mkv ~ 105 MByte (before encoder changes): http://uploaded.to/?id=fxfwcx
* 1 minute Discovery 1080i as mkv ~ 90 MByte (after encoder changes): http://uploaded.to/?id=0gqbo8

Here you can see cpu-usage (on a quad-core system), which illustrates the difference between the 
provider encoder changes (on client/xine side):

* before encoder changes: http://www.abload.de/image.php?img=noiframes2rqm.jpg
* after encoder changes: http://www.abload.de/image.php?img=noiframes3jhd.jpg

here you will see "top" and the unbalanced core usage with "vdr-sxfe" on a dual-core:

top - 12:02:35 up 7 min,  2 users,  load average: 1.10, 0.80, 0.38
Tasks:  92 total,   1 running,  91 sleeping,   0 stopped,   0 zombie
Cpu0  :100.0%us,  0.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  7.3%us,  0.7%sy,  0.7%ni, 90.3%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st
Mem:   2062360k total,   527136k used,  1535224k free,    69088k buffers
Swap:   979956k total,        0k used,   979956k free,   242396k cached

PID  USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
5708 ciax      20   0  391m 102m  49m S  101  5.1   3:58.69 vdr-sxfe
5704 root      19  -1  135m  67m  57m S    4  3.3   0:18.88 Xorg
5677 root      20   0  555m  70m  11m S    3  3.5   0:15.53 vdr
.
.

as you can see, there are two cores - one is at 100% and the process vdr-sxfe also - 
it does not scale balanced over both cores. before the provider encoder change the two 
cores were used at the same level.

* options set:

~/.xine/config includes: video.processing.ffmpeg_thread_count:2
also ~/.xine/config_xineliboutput includes that option

other options set are:
video.processing.ffmpeg_choose_speed_over_accuracy:1
video.processing.ffmpeg_pp_quality:0
video.processing.ffmpeg_skip_loop_filter:all
video.processing.ffmpeg_thread_count:2


versions:
xine-lib: HG xine-lib-1.2 pull from 12.08.2008
ffmpeg: svn from 12.08.2008 (SVN-r14496)

There are many people reporting the same symptoms. It seems that this problem can be 
pinpointed to xine/-lib.

Full of expectation for pursuing answer,
ciax
_________________________________________________________________
Windows Live Spaces - Ihr Leben, Ihr Space. Hier klicken und informieren.
http://get.live.com/spaces/overview

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
xine-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xine-user