Re: [webkit-dev] cant get libvpx repo here?
El domingo, 29 de abril de 2018 15:36:43 (CEST) tugouxp escribió: > i am compiling the latest webkit on ubuntu18.04. when i follow the manul > to do the steps: ./Tools/Scripts/update-webkitgtk-libs > i meet the problem of cant get the libvpx package. such as follows. > > this problem cant be fixed because of gov policy, you know. so is there any > other way to dealt with this problem? thanks for your kindly reply. > > git clone https://chromium.googlesource.com/webm/libvpx libvpx > Cloning into 'libvpx'... > fatal: unable to access 'https://chromium.googlesource.com/webm/libvpx/': > Failed to connect to chromium.googlesource.com port 443: Connection timed > out In https://www.webmproject.org/code you can see a list of mirrors. In your case, I would try with https://github.com/webmproject/libvpx/ Edit Tools/gstreamer/jhbuild.modules near line 22 (https://chromium.googlesource.com/webm/;>) and change it to point to the github url. If that still doesn't work and you don't find alternative ways to download the libvpx-1.7.0 library, maybe you can just disable vp8/vp9 support by getting rid of the vpx definitions in jhbuild.modules and then removing the dependency in the block. Cheers. -- Enrique Ocaña González ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] small browser video tag
El viernes, 22 de septiembre de 2017 10:45:35 (CEST) Jerry Geis escribió:
> The enable mediasource function is now being called and with the get
> mediasource function it returns 1.
> So do I assume it was built with that ability enabled? I would think it
> would return 0 if not able.
If you're using the WebKitGTK+ libraries which come with your distro, the odds
are that MSE is not enabled. You would need your own version with the right
build flags.
Run the YouTube Conformance tests[1]. If the first bunch of tests is red, then
there's some problem with the MSE support. If they're mostly green, then check
again your JavaScript code. Each of these JavaScript lines should return true:
MediaSource.isTypeSupported('video/mp4; codecs="avc1.640028"');
MediaSource.isTypeSupported('audio/mp4; codecs="mp4a.40.2"');
Have into account that we only support mp4 with h264 video and mpeg or aac
audio. Webm with vp9 and opus is currently not supported.
Cheers.
[1] http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/
2016.html?enablewebm=false=run
--
Enrique Ocaña González
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] small browser video tag
El viernes, 22 de septiembre de 2017 10:13:41 (CEST) Jerry Geis escribió: > I think this is my issue > ... window.MediaSource=window.MediaSource||window.WebKitMediaSource > Neither of these is defined. Now do I get that? Media Source Extensions (MSE) are not enabled in the release builds of WebKitGTK+. If you want MSE support, you need to build WebKitGTK+ yourself with ENABLE_MEDIASOURCE and then also enable that feature at runtime. Cheers. -- Enrique Ocaña González ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] small browser video tag
El viernes, 22 de septiembre de 2017 9:31:32 (CEST) Jerry Geis escribió: > What is my next step to tell whats happening ? I'm assuming that you're using a recent WebKitGTK+ version to build your browser. In that case, enable GStreamer logs. They might give you a clue of what's happening. To get just the messages more related to WebKit, use this: export GST_DEBUG="webkitmediaplayer:TRACE,webkitwebsrc:TRACE" To get all the messages (a lot!!), use this: export GST_DEBUG="*:DEBUG" Cheers. -- Enrique Ocaña González ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Making MockMediaPlayerMediaSource and other MediaPlayerPrivateInterface subclasses work together
El lunes, 28 de noviembre de 2016 9:21:04 (CET) Jer Noble escribió: > It’s a bit of a hack, the way this works in macOS. When a LayoutTest asks > to install the mock MSE player in Internals::initializeMockMediaSource(), > we uninstall all the AVFoundation-based MediaPlayerPrivates, including > MediaPlayerPrivateAVFoundationObjC, MediaPlayerPrivateMediaSourceAVFObjC, > and MediaPlayerPrivateMediaStreamAVFObjC. This leaves the > MockMediaPlayerMediaSource player as the only remaining installed player. The explanation is really appreciated. Now everything makes sense to me. :-) > I’m very open to ideas about how to clean this area up, since, as you noted, > we don’t even get a MIME type until long after the MediaPlayerPrivate is > created. But for now, you can add some calls to disable the standard GTK > MediaPlayerPrivates in Internals::initializeMockMediaSource(), which should > allow you to run tests correctly. The mock player private is the outsider here. I think the hack, targeted to a very restricted environment as it is, makes sense and is a good way to avoid cluttering a design which works well for the real world. Thanks a lot. -- Enrique Ocaña González ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Making MockMediaPlayerMediaSource and other MediaPlayerPrivateInterface subclasses work together
Hi, These days I've been working on improving the layout test passrate of our new Media Source Extensions GStreamer platform implementation (MediaPlayerPrivateGStreamerMSE), but I'm having problems with the selection of the right MediaPlayerPrivateInterface implementation for each use case. As I understand it (please correct me if I'm wrong), under normal circumstances (no MEDIA_SOURCE enabled) MediaPlayer tries to find the best media engine (ie: MediaPlayerPrivateInterface implementation) available to play a content. It does so by asking each engine if they support (yes/no/ maybe) the particular mime type of the video. For the "maybe" case, the engine is instantiated, loading goes forward and the networkState is set to FormatError in case something goes wrong. In that case MediaPlayer tries the next available engine. Things work different for MSE. No matter what support the engine reports, all the engines are tried and the content loading is attempted. Setting FormatError in networkState is the only way in which an engine can reject being selected. Unfortunately, it's impossible for MediaPlayerPrivateGStreamerMSE to take that decision at loading time, because usually the load happens before the MediaSource has been configured with SourceBuffers (the ones specifying a mime type). Therefore, the MSE player private must always succeed blindly on loading if it wants to have any opportunity. This works fine for real world use cases. My issue is related to MockMediaPlayerMediaSource, the test engine which should take care of the "video/mock" content used in some layout tests. Our MSE player private gets selected and performs the loading (of an empty MediaSource). However, when a video/mock SourceBuffer is added, it's too late for the MSE player private to reject being in charge. Both MediaSource and SourceBuffer are already using the GStreamer-related subclasses as their MediaSourcePrivate and SourceBufferPrivate counterparts and they can't be hot- swapped with the Mock-related subclasses. Returning NotSupported in MediaSourceGStreamer::addSourceBuffer() only makes things worse. The JavaScript code triggering that call expects addSourceBuffer() to be handled by the mock engine and to succeed on the first attempt. The JS code isn't supposed to retry the call to addSourceBuffer(). I wonder what's the right way to manage the competitive selection between the platform player private and the mock player private to make real world use cases and test use cases work together. In particular, I wonder how it can successfully work in the Mac implementation. The MediaPlayerPrivateMediaSourceAVFObjC implementation declares that it doesn't support and empty mimetype (irrelevant here, as it'll always be tried by MediaPlayer when MEDIA_SOURCE is enabled). Then, on load, it doesn't check anything so apparently succeeds. I would be really grateful if Jer Noble or anybody else with knowledge on the matter could devote some minutes to shed some light about the right way to make the mock player private and the MSE player private live together. Thank you. -- Enrique Ocaña González ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Determining the device pixel density of target device
El Martes, 4 de marzo de 2014 20:59:10 AgentX escribió: I was working with *responsive images* in Webkit and I came across this *‘deviceScaleFactor’* attribute with determines the pixel density on the target device. I was unable to find out how does Webkit determine it, that is which functions does it use and where can I find them in the Source Code? All I was able to find was that it used a function *‘page-deviceScaleFactor()’* which somehow returned the scale factor but I was unable to find the exact function which actually computes the scale factor. First of all, excuse me if some answer is inaccurate. I'm not acquainted with that part of the code and I'm only going to expose my findings just in case they might be helpful for you. TL; DR: Based on my analysis of the code, the scale factor is set by the end user program in EFL, got from NSWindow in Mac and never set in GTK+, where 1 (the default) is used. The full story: After git grepping [1][2] the code several times, I've found that WebCore::Page initializes its m_deviceScaleFactor to 1 in its constructor. Then, other code call WebCore::Page::setDeviceScaleFactor(), but that depends on each particular port. In the case of the EFL port, the actual scale factor (ratio) is set here: WebKit/efl/ewk/ewk_view.h:EAPI Eina_Bool ewk_view_device_pixel_ratio_set(Evas_Object *o, float ratio); WebKit2/UIProcess/API/efl/ewk_view.h:EAPI Eina_Bool ewk_view_device_pixel_ratio_set(Evas_Object *o, float ratio); and nobody (except the tests) uses that code, it's API for the end user program, so we can't know who actually computes the scale factor in that port. Similar delegation to external code seems to happen on Mac, either manually: WebKit/mac/WebView/WebViewPrivate.h:- (void)_setCustomBackingScaleFactor: (CGFloat)overrideScaleFactor; ...or automatically, where the scale factor is taken from NSWindow[3]: WebKit/mac/WebView/WebView.mm:- (float)_deviceScaleFactor Regarding WebKitGTK+, I haven't found any specific code to set the scale factor. Maybe they always use the default one. There's also a field in WebPageCreationParameters which determines the scale factor to be used in WebKit::WebPage at creation time by the WebProcess. Now using Eclipse's code analysis features, I've found that it's set by the UIProcess based on the result of: WebKit2/UIProcess/WebPageProxy.cpp:float WebPageProxy::deviceScaleFactor() const In the end, its value depends on WebPageProxy::setIntrinsicDeviceScaleFactor(), apparently not used by anybody, and WKPageSetCustomBackingScaleFactor(), used only by the tests and by EFL's EwkView.ewk_view_device_pixel_ratio_set(), already mentioned before. The final summary is actually the TL;DR section in the begining. Take it with a grain of salt. Of course, experts acquainted by the code have the final word on this analysis. Regards. [1] git grep deviceScaleFactor | grep -v ChangeLog [2] git grep -e '-setDeviceScaleFactor' | grep -v ChangeLog [3] https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/occ/instm/NSWindow/backingScaleFactor -- Enrique Ocaña González ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] PSA: COMPILE_ASSERT_MATCHING_ENUM is a bad idea
El Miércoles, 29 de enero de 2014 08:28:39 carlo...@webkit.org escribió: https://bugs.webkit.org/show_bug.cgi?id=127800 WebKitGTK+ should stop using COMPILE_ASSERT_MATCHING_ENUM macros Ok, let's fix this sooner rather than later, then. My apologies. It was more later rather than sooner, but the patch has landed[1]. Cheers. [1] http://trac.webkit.org/changeset/164438 -- Enrique Ocaña González ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
