[FFmpeg-devel] H.264 - interlacing artifacts fix: No balanced CPU-core usage
'it's me'
ciaccom
Tue Aug 12 18:06:32 CEST 2008
hello Michael again,
a user out of vdr-portal was so nice and attached 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
The application vdr 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).
Also another user there at that forum reported, that 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 (?).
Maybe you can give a short answer/assumption, that helps a bit to pinpoint the source of the symptoms.
Thanks a lot!
ciax
> From: ciaccom at hotmail.com
> To: ffmpeg-devel at mplayerhq.hu
> Date: Tue, 12 Aug 2008 12:08:49 +0200
> Subject: Re: [FFmpeg-devel] H.264 - interlacing artifacts fix: No balanced CPU-core usage
>
>
> hello Michael,
>
> thank you very much for your answer. i know, my description is not really knwoledgeable - so it's maybe not
> suitable to post in the devel-list. furthermore i'm not able to reproduce the old status, cause of following fact:
>
> 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+). they do not use IDR- nor I-Frames anymore, but only
> intra encodete macroblocks (info was investigated in appropriate portals). so it's not possible to illustrate the
> old status, where these frames existed in the stream.
>
> ffmpeg team then published it's 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.
>
> i'm using vdr (a linux PVR) here in conjunction with xine (HG revision) compiled with --with-external-ffmpeg (the
> ffmpeg sources, where the bug-fix was included (i don't know the exact revision of ffmpeg with the fix - should be a
> bit before rev. 14405).
>
> "top" shows this: (vdr-sxfe is the process responsible for viewing the HD-stream, it's a kind of xine-frontend/interface)
>
> 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 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.
>
> sorry - i'm complete wrong in this mailling list and maybe the problem is not ffmpeg, but xine/vdr-sxfe itself! But i'm
> not alone with these symptoms.
>
> thank you for your time and i apologize inconvenience!
> best wishes, ciax
>
>
> > Date: Mon, 11 Aug 2008 21:20:54 +0200
> > From: michaelni at gmx.at
> > To: ffmpeg-devel at mplayerhq.hu
> > Subject: Re: [FFmpeg-devel] H.264 - interlacing artifacts fix: No balanced CPU-core usage
> >
> > On Mon, Aug 11, 2008 at 01:07:21PM +0200, 'it's me' wrote:
> > >
> > > Hi there,
> > >
> > > sorry for this double post - i was not sure if "ffmpeg-user" list is appropriate for this question.
> > > 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.
> > >
> > > Especially using ffmpeg (since SVN-r14496 where the fix is included) 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). So live HD-channels are jerked now :(
> >
> > We need a complere bugreport you are missing approximately 99%
> > which exact revissiom broke it
> > which file? url of where its available
> > how to reproduce? exact command lines, exact output from whatever tool you use
> > to identify cpu useage with old and new revissions
> >
> > also this belongs to our issue tracker
> > i normally do not mind complete, short and clean bugreports on ffmpeg-dev
> > but this one doesnt look like one.
> >
> > [...]
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Dictatorship naturally arises out of democracy, and the most aggravated
> > form of tyranny and slavery out of the most extreme liberty. -- Plato
>
> _________________________________________________________________
> Windows Live Spaces - Ihr Leben, Ihr Space. Hier klicken und informieren.
> http://get.live.com/spaces/overview
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
_________________________________________________________________
Windows Live Spaces - Ihr Leben, Ihr Space. Hier klicken und informieren.
http://get.live.com/spaces/overview
More information about the ffmpeg-devel
mailing list