Closed Bug 182087 Opened 17 years ago Closed 15 years ago

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

Categories

(Camino Graveyard :: Plug-ins, defect, major)

PowerPC
macOS
defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 271050
Camino0.9

People

(Reporter: chrispetersen, Assigned: mikepinkerton)

References

Details

(Whiteboard: [need testing])

Attachments

(1 file, 1 obsolete file)

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.
Attached file Reduced test case from weather.com (obsolete) —
Tested with the Real One Player 9.0b2.
http://versiontracker.com/moreinfo.fcgi?id=15540&db=mac
Keywords: realplayer
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.
assigning QA : need testing
Whiteboard: [need testing]
*** Bug 185712 has been marked as a duplicate of this bug. ***
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.
Target Milestone: --- → Chimera0.8
Still a issue on the 2003081002 chimera NB.
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/
Severity: normal → major
Attached file 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).
Attachment #107505 - Attachment is obsolete: true
It seems to play just fine in Mozilla 1.5 though. So this seems like a Camino
specific problem.
mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp is the bulk of the gecko
plugins code, and generally that directory is where the action is.
Talked to Peter Lubczynski. He's no longer doing this, reassigning back to Mike
by default.
Assignee: peterlubczynski-bugs → pinkerton
Summary: Real video playback tends to be drop frames and appears "choppy". → Real video playback tends to drop frames and appears "choppy".
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.
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.
Target Milestone: Camino0.8 → Camino0.9
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..
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 ***
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.