182087 - Real video playback tends to drop frames and appears "choppy".

Status: RESOLVED DUPLICATE of bug 271050

(Camino Graveyard :: Plug-ins, defect)

Description

[Chris Petersen]

Build:2002-11-26-04 NB
Platform: 0S X 10.2.2
Expected Results: Real video playback should as smooth as the CFM builds.
What I got: The video playback tends to drop frames randomly which gives a
"choppy" look to the video.

Steps to reproduce:

1) First, open the reduced test case from weather.com in a CFM build (Fizzilla).
2) Notice the playback speed of the video.
3) Now , open the same test case in Chimera.
4) In Chimera, the video playback should be choppy and drop frames randomly.
Sometimes, the video playback appears to stall and not restart.

Comment 1

[Chris Petersen]

Attachment: Reduced test case from weather.com

Comment 2

[Chris Petersen]

Tested with the Real One Player 9.0b2.
http://versiontracker.com/moreinfo.fcgi?id=15540&db=mac

Comment 3

[Suraj K. Rai]

I had the same problem viewing the video content on news.com.  Since Windows
Media  Player Plugin does not work outside of IE, I tried using the Real 9
plugin and ran into choppy frames.

Comment 4

[rubydoo123]

assigning QA : need testing

Comment 5

[Steven W. Riggins]

*** Bug 185712 has been marked as a duplicate of this bug. ***

Comment 6

[Michael Lam]

I can confirm that this is a bug in Chimera. When I choose to play the same
content on the standalone player, the video does not drop frame. However, when I
play it again through Chimera, the video is choppy. Safari and IE does not
experience the problem.

I am using the highlight videos from espn.com to test the Real Player.

Comment 7

[Chris Petersen]

Still a issue on the 2003081002 chimera NB.

Comment 8

[S Woodside]

http://bugzilla.mozilla.org/show_bug.cgi?id=185712#c4 wrote:
Does changing the NULL event timers help? They are currently set to 120/60 here
in |nsPluginInstanceOwner::StartTimer|:
http://lxr.mozilla.org/mozilla/source/layout/html/base/src/nsObjectFrame.cpp#3839
http://lxr.mozilla.org/mozilla/source/modules/plugin/base/src/nsPluginViewer.cpp#1400

Comment 9

[S Woodside]

This is a major bug that gets mentioned in a lot of "things that really need to
be fixed in Camino" lists out on the net. A good URL to see real videos, Comedy
Central:
  http://www.comedycentral.com/dailyshow/

Comment 10

[S Woodside]

Attachment: new test

The previous test doens't seem to work any more, here's a new one, from
comedycentral.com.
This plays smoothly in Safari (1.0) and choppy in Camino (own build, 2 days
old, 10.2.8, TiBook 1 GHz).

Comment 11

[S Woodside]

It seems to play just fine in Mozilla 1.5 though. So this seems like a Camino
specific problem.

Comment 12

[S Woodside]

mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp is the bulk of the gecko
plugins code, and generally that directory is where the action is.

Comment 13

[S Woodside]

Talked to Peter Lubczynski. He's no longer doing this, reassigning back to Mike
by default.

Comment 14

[S Woodside]

I've been looking at this in Thread Viewer. I see two main backtraces in
evidence. This one is occurs at intervals throughout playback, even though most
of the time the video is frozen:

[A]
[...]
0x6f794e0
0x6d006b0
0x6c989ec
0x6ca094c
0x6c93500
ns4xPluginInstance::HandleEvent(nsPluginEvent*, int*)
nsPluginInstanceOwner::Notify(nsITimer*)
nsTimerImpl::Fire()
handleTimerEvent(TimerEventType*)
PL_HandleEvent
PL_ProcessPendingEvents
nsEventQueueImpl::ProcessPendingEvents()
-[EventQueueHandler eventTimer:]
__NSFireTimer
__CFRunLoopDoTimer
__CFRunLoopRun
CFRunLoopRunSpecific
RunCurrentEventLoopInMode
ReceiveNextEventCommon
BlockUntilNextEventMatchingListInMode
_DPSNextEvent
-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
-[NSApplication run]
NSApplicationMain
_start
start


this one is shows up in concentrated bursts when the video "catches up" and
starts to play:

[B]
[...]
0x70a70f0
0x7090424
0x73d1000
0x73c93e0
__CFRunLoopDoTimer
__CFRunLoopRun
CFRunLoopRunSpecific
RunCurrentEventLoopInMode
ReceiveNextEventCommon
BlockUntilNextEventMatchingListInMode
_DPSNextEvent
-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
-[NSApplication run]
NSApplicationMain
_start
start


I assume that the hex values in both cases represent the part of the stack
that's in realplayer code. But notice it's different hex values...

Then we have mozilla, I ran Thread Viewer on Mozilla 1.5 which shows this stack
at regular intervals while playing:

[C]
[...]
0x62af4e0
0x61c66b0
0x616c9ec
0x617494c
0x6167500
ns4xPluginInstance::HandleEvent(nsPluginEvent*, int*)
nsPluginInstanceOwner::Notify(nsITimer*)
nsTimerImpl::Fire()
handleTimerEvent(TimerEventType*)
PL_HandleEvent
PL_ProcessPendingEvents
_md_EventReceiverProc
DispatchEventToHandlers
SendEventToEventTargetInternal
SendEventToEventTargetWithOptions
ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*)
DispatchEventToHandlers
SendEventToEventTargetInternal
SendEventToEventTarget
ToolboxEventDispatcher(OpaqueEventRef*)
CallEventDispatchHook
TryEventDispatcher
GetOrPeekEvent
GetNextEventMatchingMask
WNEInternal
WaitNextEvent
nsMacMessagePump::GetEvent(EventRecord&)
nsMacMessagePump::DoMessagePump()
nsAppShell::Run()
main1(int, char**, nsISupports*)
main
_start
start

the hex values are very similar in A and C (I don't know why buyt the endings
are the same). Both A and C have 

ns4xPluginInstance::HandleEvent(nsPluginEvent*, int*)

at the top of the stack just before realplayer code is invoked.

Comment 15

[Simon Fraser [no longer active]]

ns4xPluginInstance::HandleEvent(nsPluginEvent*, int*)
nsPluginInstanceOwner::Notify(nsITimer*)
nsTimerImpl::Fire()
handleTimerEvent(TimerEventType*)
PL_HandleEvent

This is us sending null events to the plugin (to simulate the null events that
used to be sent to the plugin in WaitNextEvent-based apps on Classic). Plugins
needs these null events to do idle-time stuff. It's part of the horrible nest of
backward compatibility hacks that are required to make plugins work.

Comment 16

[Chris Petersen]

With the latest Realplayer 10 public beta (build 188), I'm not seeing the
typical issue with frame dropoff during the viedo playback. This was noticeable
issue happening with the previous Realplayer 9 plugin. Perhaps Real fixed
something in the their beta or it's magically fixed in the camino trunk :). I'm
using the latest Camino trunk - 2004071708 (v0.8+) under 10.3.4. My test mac is
a Power Mac G4 Dual 450 G4. 


Here are some URL's I tested with:

http://news.com.com/1606-2-5250761.html

http://news.com.com/1606-2-5273055.html

There are still some painting issues with the plugin when I resize the browser
window. Also,  I can't get the plugin's contextual menu on appear either when
mouse down on the plugn content. BUT now, the original frame drop issue is gone
from me..

Comment 17

[Mike Pinkerton (not reading bugmail)]

i think this is a dupe of 271050, please test these urls with the builds made
from patches in that bug, reopen if they don't fix the issue.

*** This bug has been marked as a duplicate of 271050 ***