Re: [webkit-dev] Request for position: Media Session video conferencing actions

[Eric Carlson via webkit-dev]

> On Mar 24, 2021, at 4:01 PM, Tommy Steimel via webkit-dev 
>  wrote:
> 
> This is a request for WebKit's position on adding video conferencing actions 
> to the Media Session API spec. Note that this is the proposal that was 
> discussed on the March 9th 2021 Media WG meeting.
> 
> Spec change explainer:
> https://gist.github.com/steimelchrome/d52f0fb9a0a13c63a3cf2d4134b71682 
> 
> 
> Discussion (first comment is a copy of the explainer above):
> https://github.com/w3c/mediasession/issues/264 
> 
> 
> Summary:
> 
> To make the Media Session API more useful for video conferencing websites, 
> we'd like to add "togglemicrophone", "togglecamera", and "hangup" actions to 
> the list of supported Media Session Actions.
> 

  We are generally supportive of this proposal. 

  Thanks for updating the proposal after on our discussions in the recent Media 
WG meeting!

eric

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Formatting style for inline comments in Python code

[Eric Carlson]

> On Oct 26, 2017, at 9:50 AM, Brian Burg  wrote:
> 
> 
> 
>> 2017/10/26 午前9:21、Alexey Proskuryakov > >のメール:
>> 
>> 
>> 
>>> 25 окт. 2017 г., в 18:21, Michael Catanzaro >> > написал(а):
>>> 
>>> On Wed, Oct 25, 2017 at 4:58 PM, Aakash Jain >> > wrote:
 Does anyone else has any opinion/preference for this?
>>> 
>>> The number of spaces before a comment really does not matter, but my $0.02: 
>>> PEP8 is an extremely common style for Python programs that all Python 
>>> developers are familiar with. I would follow that, and forget about trying 
>>> to adapt WebKit C++ style to an unrelated language. Trying to adapt the 
>>> style checker to ignore particular PEP8 rules seems like wasted effort.
>> 
>> 
>> There is definitely a number of PEP8 rules that we want to follow. But I 
>> don't think that there is anything about the two space before comment rule 
>> that makes it particularly fitting for Python.
> 
> This is entirely subjective, so: why differ from the vast majority of all 
> other Python code in existence, just to be different? What's the point? PEP8 
> adherence is nearly universal among projects on PyPi, at least among those 
> that run style linters.
> 
>> I think that we should target WebKit developers with the coding style as 
>> much as possible, not Python developers. As we all agree on the one space 
>> rule elsewhere, why make a part of the code base uncomfortably different for 
>> most WebKit developers?
> 
> I don't understand the distinction between WebKit developers and Python 
> developers. Am I not a C++ developer and web developer as well?
> 
> If "WebKit developers" want to write Python code, perhaps they should learn 
> the Pythonic idioms of the language, just as they would use idioms of Perl, 
> JavaScript, and C++. For better or worse, PEP8 encodes many of these idioms.
> 
> If someone already knows Python, they will be tripped up by this divergence 
> and waste some minutes trying to satisfy the style checker, or just ignore 
> it. If they don't know Python well, then they are being conditioned to follow 
> some variant that has no benefit and is different from what they would see in 
> any other Python code.
> 
> I see no value in adding arbitrary barriers to new contributions in Python 
> code. The code has enough problems as-is, we don't need to make up our own 
> for some pretense of consistency. We import other Python projects into the 
> tree, and they follow PEP8, so what was proposed is to make the Python code 
> in the tree *less* internally consistent.
> 

+1

eric


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Trying to turn WebRTC's code on - MEDIA_STREAM flags

[Eric Carlson]

> On Jul 18, 2014, at 3:17 AM, Jacques-Olivier  wrote:
> 
> I’m new on this mailing so I’ll start by introducing myself:
> My name Jacques-Olivier Haché (J-O), I’m working for Temasys Communication, 
> and I’m entering the WebKit project to work on the implementation of WebRTC 
> inside WebKit.
> For those who would be following the WebRTC’s news, I’m also the main 
> developer of the WebRTC plugin released by Temasys.
> 

  Welcome to the WebKit community!

> I am now trying to enable the WebRTC related features to get a better 
> understanding of the current state of this part of the project. 
> I have to say that I faced a lack of documentation on this area. I found the 
> features list , a document about 
> how to add a new feature  but 
> nothing about how to turn a feature on and off (there is actually a TODO 
> about that in the second link).
> 
> I looked into the files that one needs to change to add a new feature and 
> found two interesting files:
> Source/WTF/wtf/FeatureDefines.h - where the WebRTC related contants were set 
> to 0 instead of 1
> Source/cmake/WebKitFeatures.cmake - where the contants were set to OFF
> I listed the following definitions that look related to WebRTC
> ENABLE_MEDIA_CAPTURE
  This flag is for features in the HTML Media Capture spec: 
http://www.w3.org/TR/html-media-capture/

> ENABLE_MEDIA_CONTROLS_SCRIPT
  This is for the JavaScript-based  and  controls some ports us.

> ENABLE_MEDIA_SOURCE
  This is for the Media Source Extension spec: 
http://www.w3.org/TR/media-source/
  
> ENABLE_MEDIA_STATISTICS
  This is for an experimental HTMLMediaElement statistics feature enabled by 
some ports.

> ENABLE_MEDIA_STREAM
  This is for the Media Capture and Streams spec: 
http://w3c.github.io/mediacapture-main/
> ENABLE_VIDEO
  This is for  and  in general.

> ENABLE_VIDEO_TRACK
  This is for WebVTT.

  You should not need to change any of these flags to build for the Mac.


> I turned those definitions to 1 and ON in the respective file and tried to 
> build.
> The code in the header WebCore/Modules/mediastream/mediastream.h could not 
> compile apparently because the observer did not have a destructor. I created 
> one:
> class Observer {
> public:
> virtual void didAddOrRemoveTrack() = 0;
>   virtual ~Observer() {};
> };
> 
  It sounds like your sources are not up to date, I fixed this in 
https://trac.webkit.org/r175066

> 
> I now have a linking error that I do not understand when building WebCore 
> with Xcode. 
> 
> Ld 
> 
> Undefined symbols for architecture x86_64:
>   "__ZN7WebCore11JSNavigator18webkitGetUserMediaEPN3JSC9ExecStateE", 
> referenced from:
>   
> __ZN7WebCore46jsNavigatorPrototypeFunctionWebkitGetUserMediaEPN3JSC9ExecStateE
>  in JSNavigator.o
>   "__ZN7WebCore15RTCOfferOptions6createERKNS_10DictionaryERi", referenced 
> from:
>  
> __ZN7WebCore17RTCPeerConnection11createOfferEN3WTF10PassRefPtrINS_29RTCSessionDescriptionCallbackEEENS2_INS_30RTCPeerConnectionErrorCallbackEEERKNS_10DictionaryERi
>  in RTCPeerConnection.o
>   
> "__ZN7WebCore20MediaConstraintsMock17verifyConstraintsEN3WTF10PassRefPtrINS_16MediaConstraintsEEE",
>  referenced from:
>   
> __ZN7WebCore21MockMediaStreamCenter26validateRequestConstraintsEN3WTF10PassRefPtrINS_25MediaStreamCreationClientEEENS2_INS_16MediaConstraintsEEES6_
>  in MockMediaStreamCenter.o
>   
> __ZN7WebCore21MockMediaStreamCenter17createMediaStreamEN3WTF10PassRefPtrINS_25MediaStreamCreationClientEEENS2_INS_16MediaConstraintsEEES6_
>  in MockMediaStreamCenter.o
>   "__ZN7WebCore21RTCOfferAnswerOptions6createERKNS_10DictionaryERi", 
> referenced from:
>   
> __ZN7WebCore17RTCPeerConnection12createAnswerEN3WTF10PassRefPtrINS_29RTCSessionDescriptionCallbackEEENS2_INS_30RTCPeerConnectionErrorCallbackEEERKNS_10DictionaryERi
>  in RTCPeerConnection.o
>   
> "__ZN7WebCore4toJSEPN3JSC9ExecStateEPNS_17JSDOMGlobalObjectEPNS_16RTCConfigurationE",
>  referenced from:
>   
> __ZN7WebCore52jsRTCPeerConnectionPrototypeFunctionGetConfigurationEPN3JSC9ExecStateE
>  in JSRTCPeerConnection.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> 
  I don’t get these errors when I build, I suspect they will go away for you 
when you update your sources to TOT.


> 
> Is anyone used to turn the WebRTC code on and off?
> 

  WebKit’s WebRTC implementation is currently in a state of flux, moving from a 
platform API that maps closely to the RTC JavaScript API to a more abstract 
interface will make it easier to use different backend libraries. See bugs 
https://webkit.org/b/150165 and https://webkit.org/b/150166 for example.

eric


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: Stop EWS bot commenting in bugs

[Eric Carlson]

On Jan 27, 2014, at 5:39 PM, Chris Fleizach cfleiz...@apple.com wrote:

 I dislike this change now that's been rolled out. 
 
 The lack of email notices before confirmed that my patch was OK and I was 
 able to do something else while waiting for review.
 Now I have to continually revisit the bug page checking to see if more bots 
 have completed and that my patch is good.
 
 I think at least the person who submitted the patch should be notified when 
 there's been an error.
 
  I agree that it would be nice for the patch author to be notified when there 
is an error.

eric


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] HTML5 Body onLoad event not firing

[Eric Carlson]

On Jan 14, 2013, at 2:29 AM, ankit srivastav ank@gmail.com wrote:

 
 I'm working for Webkit WIN32 port.
 I'm facing an issue :
 
 1) For HTML5 video tag:
 
 videoonload = onLoad()
src = E:/xyz.mp4
 
 for the above mentioned code onLoad fucntion is not firing.
 but if I remove src tag value onLoad event will start firing.
 
 I have debugged and found that, 
 :checkCompleted() is exiting from 
  if (m_frame-document()-isDelayingLoadEvent())
 return;
 and thus Implicit Close is not firing.
 
 
 Please let me know if there is any solution.
 

  Please file a bug at https://bugs.webkit.org with a reproducible test case.

eric


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Cherry-Pick Bug Comments

[Eric Carlson]

On Jun 3, 2011, at 2:30 PM, Adam Barth wrote:

 Either (1) or (2) is fine.  Please pick one and do it.  The status quo
 is very annoying.
 
  Yes, please!

eric


 
 
 On Tue, May 31, 2011 at 6:58 AM, Ademar Reis ademar.r...@openbossa.org 
 wrote:
 On Thu, May 26, 2011 at 7:54 PM, Eric Seidel e...@webkit.org wrote:
 I get a lot of these:
 Revision r86028 cherry-picked into qtwebkit-2.2 with commit 7e1bab1
 http://gitorious.org/webkit/qtwebkit/commit/7e1bab1
 as bug mail.  Probably because I'm CC'd on a zillion bugs (and actually read
 my bug mail).
 
 This is probably the pot calling the kettle black, since I wrote many of the
 bots which comment daily on bugs...
 ...but, I'm wondering if we can do better?
 Would it better serve the cherry-picker's needs if we instead had a separate
 server to track revision - cherry-picks?  Or bug ids - cherry-picks? (Like
 how the EWS bots store their status on queues.webkit.org and display it in
 little bubbles on bugs.webkit.org w/o commenting on the bugs.)
 
 I'm strongly supportive of all clients of webkit storing all of their
 bug-related data in bugs.webkit.org.  It's better than the alternative (lots
 of data buried in old Radars, or Chromium bugs, etc.)
 
 Hi again.
 
 Just so that this thread doesn't die. I think we have two good
 proposals on the table:
 
 1. Track cherry-pick info on an external server and add an iframe
 inside bugzilla, the same way EWS bots do.
 Pros: scalable, any vendor could add their own trackers (would it be
 interesting to add rdar:// comments using this same mechanism?)
 
 2. Configure/hack bugzilla to allow the addition of comments without
 trigerring e-mails.
 Pros: small change, appears to be easy to implement - specially on my side 
 ;-)
 
 Eric: how do we proceed from now?
 
 In the meanwhile, please be patient with the cherry-pick e-mails... As
 usual there will be a few of them this week (in average, something
 like 20-30 cherry-picks per week).
 
 Thanks,
  - Ademar
 
 --
 Ademar de Souza Reis Jr. ademar.r...@openbossa.org
 Nokia Institute of Technology
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] skipping tests on Chromium

[Eric Carlson]

On Aug 30, 2010, at 8:59 AM, Dimitri Glazkov wrote:

 We never had platform/chromium/Skipped, as far as I know.
 

  Ah, I saw that platform/chromium/Skipped was removed in r66261 and assumed it 
was a change.

 Instead, we
 use the expectations file:
 http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium/test_expectations.txt
 
 Instead of skipping tests, we still run them, but expect them to fail.
 This allows for both being able to see how the test fails and pulling
 down baselines when it just needs to be updated.
 
  What is the correct METADATA for a new media test that doesn't apply to 
Chromium (it is for a QuickTime specific behavior)? I think the test will fail 
because it uses a movie you probably don't support, so filing a bug seems like 
unnecessary busy work. I think the test will time out but I don't know so what 
is the correct EXPECTATIONS?

eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Web Audio API

[Eric Carlson]

Chris -

On Aug 24, 2010, at 4:47 PM, Chris Rogers wrote:

 Hi Simon, thanks for helping here.
 
 By the way, anybody who is interested can look at the files in:
 https://svn.webkit.org/repository/webkit/branches/audio/WebCore/audio/
 
 There are actually a number of audio files which could be considered 
 re-usable, although I know of nothing at this time other than the web audio 
 API which would use them:
 
 AudioBus.cpp
 Biquad.cpp
 Reverb.cpp
 FFTConvolver.cpp (and other FFT-related files)
 
 possibly also in this category are:
 Cone.cpp
 Distance.cpp
 MidSide.cpp
 SinWave.cpp
 Panner.cpp (and subclasses)
 (maybe a few others I've missed)
 
 Basically, these are the lowest-level building blocks which the higher-level 
 parts (such as AudioContext, and AudioNode) use.  These lowest-level building 
 blocks do not (or should not) have any dependencies to the higher-level code 
 which implement the actual API (and have IDL files).  They also don't have 
 any dependencies on other parts of WebCore, although they do use stuff in wtf.
 
 So are you suggesting:
 
 WebCore/webaudio--- IDL files and API implementation
 WebCore/platform/audio--- lower-level building blocks such as 
 AudioBus.cpp
 
  This sounds good to me!

eric

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Web Audio API

[Eric Carlson]

On Aug 24, 2010, at 8:39 PM, Darin Fisher wrote:

 My objection (and it's only a slight one) was about using Web as a prefix 
 for class names defined in WebCore.
 
 WebSockets is the main example of the Web prefix used in WebCore, and that's 
 probably because sockets by itself would be too confusing.  However, I have 
 found the use of the Web prefix in WebCore to lead to some confusion by 
 itself since WebKit layers tend to use the Web prefix for their 
 classes/interfaces.
 
 I realize that the WebCore:: namespace makes this issue technically moot.  
 I'm just concerned about it being confusing to have WebCore::WebFoo and 
 WebKit API level WebFoo.
 
  I don't think there is any plan to give the *class* name a Web prefix, we 
are just talking about the names of the WebKit folders and the compile flag.

eric



 
 
 On Tue, Aug 24, 2010 at 5:29 PM, Chris Rogers crog...@google.com wrote:
 Good, it looks like we're getting close.  So we've agreed to how the files 
 should be split up, but Darin Fisher still was concerned about the 'web' 
 prefix.
 
 Darin, was it the directory name WebCore/webaudio that you didn't like or:
 #if ENABLE(WEB_AUDIO)
 
 Alternatives might be:
 
 WebCore/audio   orWebCore/audiocontext
 #if ENABLE(AUDIO_CONTEXT) or  #if ENABLE(AUDIO_API)
 
 I'm assuming that WebCore/platform/audio we can all agree on...
 
 Chris
 
 
 On Tue, Aug 24, 2010 at 5:20 PM, Simon Fraser simon.fra...@apple.com wrote:
 On Aug 24, 2010, at 4:47 PM, Chris Rogers wrote:
 
 Hi Simon, thanks for helping here.
 
 By the way, anybody who is interested can look at the files in:
 https://svn.webkit.org/repository/webkit/branches/audio/WebCore/audio/
 
 There are actually a number of audio files which could be considered 
 re-usable, although I know of nothing at this time other than the web audio 
 API which would use them:
 
 AudioBus.cpp
 Biquad.cpp
 Reverb.cpp
 FFTConvolver.cpp (and other FFT-related files)
 
 possibly also in this category are:
 Cone.cpp
 Distance.cpp
 MidSide.cpp
 SinWave.cpp
 Panner.cpp (and subclasses)
 (maybe a few others I've missed)
 
 Basically, these are the lowest-level building blocks which the higher-level 
 parts (such as AudioContext, and AudioNode) use.  These lowest-level 
 building blocks do not (or should not) have any dependencies to the 
 higher-level code which implement the actual API (and have IDL files).  They 
 also don't have any dependencies on other parts of WebCore, although they do 
 use stuff in wtf.
 
 So are you suggesting:
 
 WebCore/webaudio--- IDL files and API implementation
 WebCore/platform/audio--- lower-level building blocks such as 
 AudioBus.cpp
 
 Fine by me!
 
 
 then with the conditional
 
 #if WEB_AUDIO- I added an underscore here
 
 That would be #if ENABLE(WEB_AUDIO) in the code.
 
 Simon
 
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] A bot-filled future?

[Eric Carlson]

On Nov 12, 2009, at 8:20 PM, Adam Roben wrote:


On Nov 12, 2009, at 6:59 PM, Ojan Vafai wrote:


It's also easy to spot tests with FAIL or PASS in the output. :)


I'd hope that those tests would have cross-platform results, since  
clearly the condition is testable without having access to a full  
render tree dump.


  Creating and maintaing cross-platform results is a real challenge  
in some cases. With HTMLMediaElement tests, for example, we have to  
deal with the fact that different ports uses different backend media  
engines and not all ports support support the same file formats and  
codecs. This means it can be impossible to predict results without  
actually running a tests in each port. Having a try server would be  
quite helpful for these types of tests.


eric

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] LayoutTests take too long to run

[Eric Carlson]

On Aug 1, 2009, at 10:52 AM, Ojan Vafai wrote:


Here's the times for the five slowest top-level directories:
LayoutTests\editing took 43.5 seconds to run 976 tests.
LayoutTests\svg took 53.7 seconds to run 891 tests.
LayoutTests\fast took 378.7 seconds to run 3695 tests.
LayoutTests\http took 396.9 seconds to run 632 tests.
LayoutTests\media took 596.3 seconds to run 84 tests.

This might be Chromium specific, but I'm seeing many of the the  
media layout tests taking 8-10 seconds.


  That seems unusually high, on a MacBook with TOT debug build the  
slowest test (video-played.html) takes less than 4 seconds. Running  
all of the media tests takes ~40 seconds:


eric% run-webkit-tests --debug --slowest LayoutTests/media/

40.87s total testing time

The 10 slowest tests:

3.23 secs: media/video-played.html
2.53 secs: media/audio-constructor-autobuffer.html
2.05 secs: media/video-played-collapse.html
1.93 secs: media/video-loop.html
1.53 secs: media/controls-after-reload.html
1.39 secs: media/event-attributes.html
1.35 secs: media/video-aspect-ratio.html
1.16 secs: media/video-timeupdate-during-playback.html
1.12 secs: media/video-played-reset.html
1.09 secs: media/audio-data-url.html

eric

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Chrome build bot

[Eric Carlson]

Chrome hackers -

  When do you plan to have a build bot on build.webkit.org?

  I broke your build yesterday with http://trac.webkit.org/changeset/45572 
, but didn't realize it so Albert had to clean up after me (again,  
thanks Albert).


  I *try* not to break other builds but the media element backends  
are, by definition, platform specific it is easy to miss something. I  
always watch the build bots after a check-in so I can fix things, but  
that doesn't help me with your builds.


eric

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] audio/source and the type attribute

[Eric Carlson]

John-Paul -

On Apr 1, 2009, at 2:37 AM, Harold, John-Paul wrote:


On Tue, 31 Mar 2009, Harold, John-Paul wrote:


in my HTML5 audio markup, I have the following

audio
 source src=/media/audio/ogg/9001_1/9807.ogg

type=audio/ogg;

codecs=vorbis/
 source src=/media/audio/m4a/9001_1/9807.m4a/
/audio

but I'm unsure what the equivalent type attribute for an m4a file
should be. Can someone advise?


Does this help?:

  http://www.whatwg.org/specs/web-apps/current-work/#attr-source-type



normally, reading the docs does help :-) However, in my example, I  
have

previously tried the following,

source src=/media/audio/m4a/9001_1/9807.m4a type= audio/mp4;
codecs=quot;mp4a.40.2quot;/

Using this, Safari stops playing the audio. It works without any type
attribute, but that feels wrong. I'm wondering if my attempts so far
have been using an incorrect mime-type, or/and a wrong codec
declaration.

I'm wondering if this has something to do with the issue,
https://lists.webkit.org/pipermail/webkit-unassigned/2008-August/081596 
.

html

  Not dealing with parameters on a type attribute at all was fixed  
last August, see https://bugs.webkit.org/show_bug.cgi?id=20360.


  The issue you are seeing here is caused by a problem with WebKit's  
interaction with QuickTime on the Mac. Can you please file a bug  
report on https://bugs.webkit.org/ ?


  Thanks for pointing out the issue,

eric

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] writing NPAPI plugins for video tag

[Eric Carlson]

Sriram -

On Feb 24, 2009, at 1:28 AM, Sriram Neelakandan wrote:


Is there an NPAPI plugin extension available to say that the plugin
supports video tag
For example a set of methods / properties, which map directly to  
video tag.

i.e play(), pause(), etc..map to a direct NPAPI method on the plugin
with the same JS name

I am not sure if this is what is called as proxy plugin for video  
tag.

PLUGIN_PROXY_FOR_VIDEO


From the code in RenderPartObject.cpp

serviceType = application/x-media-element-proxy-plugin;
it is clear that  the plugin should support this new mime-type..

1. Please correct me if the above observation is incorrect
2. Is there any other requirements that the plugin needs to meet ?
3. Is there a sample NPAPI proxy plugin  ..  probably based on
gstreamer or mplayer .
4. Is there some documentation related to NPAPI extension for video
tag handling ?

  Yes, the PLUGIN_PROXY_FOR_VIDEO switch is intended to allow a port  
to use a plug-in to implement the video/audio back-end. It is not  
currently plumbed through WebKit for NPAPI plug-ins, only for Mac  
WebKit plug-ins.


  There isn't a sample plug-in but the concept is fairly simple: an  
object that implements MediaPlayerPrivateInterface (media engine  
implementation) calls an interface exposed by a plug-in to set up and  
control a media file, and the plug-in calls an interface on the  
HTMLMediaElement to inform the implementation of media state changes.


  It should be fairly easy to figure out by looking at the code  
inside of PLUGIN_PROXY_FOR_VIDEO.


  To implement it for NPAPI plug-ins, you will need to:

  + define the media control interface an NPAPI plug-in will  
implement (see MediaPlayerProxy.h for the ObjC interface used by a  
WebKit plug-in).
  + write an object that implements MediaPlayerPrivateInterface that  
knows how to deal with the plug-in interface and notifications.
  + define a mechanism for an NPAPI plug-in to pass an object that  
implements this interface back to the HTMLMediaElement (see  
WebPluginContainerPrivate.h for the WebKit plug-in version), which  
will pass it to your engine implementation.


eric



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Webkit Building errors in VC++2005

[Eric Carlson]

On Feb 22, 2009, at 12:18 AM, Frank Thomsen wrote:

I read that wiki page, as well as followed the guidelines beginning  
with http://webkit.org/building/tools.html to the lette. I had two  
colleagues do the same – same result. It was when I found the link  
included in the last mail that I finally got a breakthrough. There  
is just too much information missing in the “official” guidelines,  
I’m sorry to say. I would advice someone to rewrite it J


Regards
Frank

  The webkit.org pages are also in the source tree. *You* can fix any  
errors and/or omissions you find and submit patches for them.


eric___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev