Bug 12875

The duration is fixed in git (or maybe youtube fixed their player).  As for 100% utilization, I've never seen it with youtube (if it's just one page).

(In reply to comment #1)
> The duration is fixed in git (or maybe youtube fixed their player).

Thanks.

> As for 100% utilization, I've never seen it with youtube (if it's just one
> page). 

For example, the following videos produce the problem on my system:

http://www.youtube.com/watch?v=S-cV2-HWoV0
http://www.youtube.com/watch?v=SDwyBWjfFaM

while other videos (both youtube and non-youtube) work just fine.

While playing, they are jerky and top reports the following:

top - 12:32:31 up  2:03,  1 user,  load average: 0.66, 0.42, 0.34
Tasks:  77 total,   2 running,  75 sleeping,   0 stopped,   0 zombie
Cpu(s): 99.3%us,  0.3%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.3%hi,  0.0%si,  0.0%st
Mem:    766488k total,   602516k used,   163972k free,    22584k buffers
Swap:  1004020k total,        0k used,  1004020k free,   318660k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 4916 root      25   0  256m  68m  13m R 74.9  9.2   6:50.43 X
 5471 shr       15   0  483m 122m  23m S 24.0 16.4   0:29.31 firefox-bin

# cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 4
model name      : AMD Athlon(tm) 64 Processor 3000+
stepping        : 8
cpu MHz         : 1800.000
cache size      : 1024 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow up
bogomips        : 3591.75
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp

Also, while doing the test I've noticed that, regardless of the video, youtube player controls (volume slider, progress bar slider) are unusable (ie, undraggable), while "pause" and "restart" button work fine.

If you need additional info, just ask.

Thanks

I can confirm that the duration was fixed in swfdec, since version 0.5.3 shows 2:48, but the version from git shows the correct value.

But I cannot see anything wrong with those videos.  They use 50% CPU (it's a dual-CPU system), but so do all other videos I have tried.  Compiling swfdec with ffmep and mad makes no difference for me.

(In reply to comment #3)

> But I cannot see anything wrong with those videos.  They use 50% CPU (it's a
> dual-CPU system), but so do all other videos I have tried.  Compiling swfdec
> with ffmep and mad makes no difference for me.

I actually use it with ffmpeg and mad enabled.
Using another, more powerful, box (athlon 64 X2), playback is smooth and CPU usage does not go above 25%. Same config (same OS, same options, same swfdec, same swfdec options)

Thus it's probably a problem related to underpowered hardware (the first box is a notebook, after all).

Both are 64-bit systems (running 64 bit userland binaries), if this matters.

However, the volume and progress bar sliders of youtube player are still unusable.

Thanks for your work!

So, I guess one issue is not a bug and the other has been solved.  Should be OK to close.

The sliders not working is filed as bug 13051 - so I guess we can close it, even though I'm wondering why only those 2 files had the problem.

(In reply to comment #6)
> The sliders not working is filed as bug 13051 - so I guess we can close it,
> even though I'm wondering why only those 2 files had the problem.

Well, it's not just those two. I did some other tests with the notebook, and I saw that CPU usage is always quite high on this box (always > 70%, even when playback is smooth). 
I mean, CPU usage varies from video to video, but it's constant for the same video during playback.

For videos whose CPU usage during playback is not higher than, say, 95%, playback looks smooth. For videos that require more CPU, playback starts to be jerky.

At this point, it looks like a problem caused by slightly unpowered hardware (I guess).

Thanks

(In reply to comment #7)

> Well, it's not just those two. I did some other tests with the notebook, and I
> saw that CPU usage is always quite high on this box (always > 70%, even when
> playback is smooth). 

During playback, of course. When not playing videos, CPU usage is around 0%, as should be.