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

'it's me' <ciaccom <at> hotmail.com> writes:

> 
>>>> 
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 (--> files are not
there anymore!!):

* 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.38Tasks:  92
total,   1 running,  91 sleeping,   0 stopped,   0 zombieCpu0  :100.0%us, 
0.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu1  :  7.3%us, 
0.7%sy,  0.7%ni, 90.3%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%stMem:   2062360k
total,   527136k used,  1535224k free,    69088k buffersSwap:   979956k total, 
      0k used,   979956k free,   242396k cached

PID  USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND5708 ciax   
  20   0  391m 102m  49m S  101  5.1   3:58.69 vdr-sxfe5704 root      19  -1 
135m  67m  57m S    4  3.3   0:18.88 Xorg5677 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
>>>>
>


hello xine-user list!

is/was there any progress concerning the problem described below?

greets, ciax 


------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/