Recherche avancée

Médias (0)

Mot : - Tags -/xmlrpc

Aucun média correspondant à vos critères n’est disponible sur le site.

Autres articles (71)

  • (Dés)Activation de fonctionnalités (plugins)

    18 février 2011, par

    Pour gérer l’ajout et la suppression de fonctionnalités supplémentaires (ou plugins), MediaSPIP utilise à partir de la version 0.2 SVP.
    SVP permet l’activation facile de plugins depuis l’espace de configuration de MediaSPIP.
    Pour y accéder, il suffit de se rendre dans l’espace de configuration puis de se rendre sur la page "Gestion des plugins".
    MediaSPIP est fourni par défaut avec l’ensemble des plugins dits "compatibles", ils ont été testés et intégrés afin de fonctionner parfaitement avec chaque (...)

  • Le plugin : Podcasts.

    14 juillet 2010, par

    Le problème du podcasting est à nouveau un problème révélateur de la normalisation des transports de données sur Internet.
    Deux formats intéressants existent : Celui développé par Apple, très axé sur l’utilisation d’iTunes dont la SPEC est ici ; Le format "Media RSS Module" qui est plus "libre" notamment soutenu par Yahoo et le logiciel Miro ;
    Types de fichiers supportés dans les flux
    Le format d’Apple n’autorise que les formats suivants dans ses flux : .mp3 audio/mpeg .m4a audio/x-m4a .mp4 (...)

  • Publier sur MédiaSpip

    13 juin 2013

    Puis-je poster des contenus à partir d’une tablette Ipad ?
    Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir

Sur d’autres sites (12322)

  • Android : FFMpeg video creation crashes with no exception when loading binaries in lower APIs (18 in my case)

    29 avril 2019, par Diego Perez

    I have an app that uses FFMpeg for video creation (these next lines are the relevant build.gradle plugin files) :

    //writingminds
    api 'com.writingminds:FFmpegAndroid:0.3.2'
    //JavaCV video
    api group: 'org.bytedeco', name: 'javacv', version: '1.4.4'
    api group: 'org.bytedeco.javacpp-presets', name: 'opencv', version: '4.0.1-1.4.4', classifier: 'android-arm'
    api group: 'org.bytedeco.javacpp-presets', name: 'ffmpeg', version: '4.1-1.4.4', classifier: 'android-arm'

    And my app is working (and creating video) just fine in my phone with a newer Android 8 version but I’m having weird problems in my old API 18 tablet (where, as a note, I had to install multidex).

    These next lines are the main part of FFMpeg video creation, where binaries are loaded, and, in fact, binaries load are where app crashes in my old tablet in the line "ffmpeg.loadBinary(new LoadBinaryResponseHandler()..."

    As you can see, I have a try/catch where the app crashes, but it crashes with no exception, as catch blocks are never hit.

    public static String recordVideo(JSONObject objJSON) {

       String strReturn = Enum.Result.OK;

       try {
           fileName = objJSON.has("file_name") ? String.valueOf(objJSON.getString("file_name")) : "";
           videoPath = objJSON.has("video_path") ? String.valueOf(objJSON.getString("video_path")) : "";
       } catch (JSONException e) {
           ExceptionHandler.logException(e);
       }

       FFmpeg ffmpeg = FFmpeg.getInstance(ApplicationContext.get());
       try {
           ffmpeg.loadBinary(new LoadBinaryResponseHandler() {

               @Override
               public void onStart() {}

               @Override
               public void onFailure() {}

               @Override
               public void onSuccess() {}

               @Override
               public void onFinish() {}
           });
       } catch (FFmpegNotSupportedException e) {
           // Handle if FFmpeg is not supported by device
       } catch (Exception e) {

       }
    ...

    These next lines are the relevant part of the LogCat, but I cannot figure out where the problem resides, maybe an out of memory problem ?

    Any help will be much appreciated.

    04-28 21:44:45.873 13743-13964/com.artandwords.thoughtoftheday A/libc: Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 13964 (AsyncTask #4)
    04-28 21:44:45.973 144-144/? I/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
    04-28 21:44:45.983 144-144/? I/DEBUG: Build fingerprint: 'asus/WW_epad/ME302C:4.3/JSS15Q/WW_epad-V5.0.21-20140701:user/release-keys'
    04-28 21:44:45.983 144-144/? I/DEBUG: Revision: '0'
    04-28 21:44:45.983 144-144/? I/DEBUG: pid: 13743, tid: 13964, name: AsyncTask #4  >>> com.artandwords.thoughtoftheday <<<
    04-28 21:44:45.983 144-144/? I/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
    04-28 21:44:46.003 144-144/? I/DEBUG:     eax 00000000  ebx 000000c6  ecx 00000000  edx 00000000
    04-28 21:44:46.003 144-144/? I/DEBUG:     esi 00000e59  edi 00000000
    04-28 21:44:46.003 144-144/? I/DEBUG:     xcs 00000073  xds 0000007b  xes 0000007b  xfs 00000043  xss 0000007b
    04-28 21:44:46.003 144-144/? I/DEBUG:     eip 784ed378  ebp 2200ff0c  esp 2200fec4  flags 00210246
    04-28 21:44:46.003 144-144/? I/DEBUG: backtrace:
    04-28 21:44:46.003 144-144/? I/DEBUG:     #00  pc 00087378  /system/lib/libhoudini.so.3.4.7.44914
    04-28 21:44:46.003 144-144/? I/DEBUG:     #01  pc 00085d0e  /system/lib/libhoudini.so.3.4.7.44914
    04-28 21:44:46.003 144-144/? I/DEBUG:     #02  pc 00073328  /system/lib/libhoudini.so.3.4.7.44914
    04-28 21:44:46.003 144-144/? I/DEBUG:     #03  pc 0006f7ff  /system/lib/libhoudini.so.3.4.7.44914
    04-28 21:44:46.003 144-144/? I/DEBUG:     #04  pc 0006f3bf  /system/lib/libhoudini.so.3.4.7.44914
    04-28 21:44:46.003 144-144/? I/DEBUG:     #05  pc 000b92de  /system/lib/libhoudini.so.3.4.7.44914
    04-28 21:44:46.003 144-144/? I/DEBUG:     #06  pc ffffffff  <unknown>
    04-28 21:44:46.003 144-144/? I/DEBUG:     #07  pc 001445aa  /system/lib/libhoudini.so.3.4.7.44914
    04-28 21:44:46.013 144-144/? I/DEBUG: stack:
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b436850  00000000  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b436854  00000000  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b436858  00000000  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b43685c  00000000  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b436860  00000000  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b436864  00000000  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b436868  00000000  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b43686c  3822676c  /system/lib/arm/libc.so
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b436870  7b436a98  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b436874  00000000  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b436878  7b4368c8  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b43687c  7b436a98  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b436880  383003a0  /system/lib/arm/libdl.so
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b436884  00000000  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b436888  7b4368c8  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b43688c  785aa5ab  /system/lib/libhoudini.so.3.4.7.44914
    04-28 21:44:46.013 144-144/? I/DEBUG:     #07  7b436890  7b4368a0  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b436894  00000000  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b436898  00000000  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b43689c  00000000  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b4368a0  7b4368c8  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b4368a4  7b436890  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b4368a8  785aa59d  /system/lib/libhoudini.so.3.4.7.44914
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b4368ac  7b436a98  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b4368b0  7b437930  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b4368b4  220001d0  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b4368b8  7b436a70  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b4368bc  00000000  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b4368c0  00000000  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b4368c4  00000000  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b4368c8  7b436a88  
    04-28 21:44:46.013 144-144/? I/DEBUG:          7b4368cc  785f3141  /system/lib/libhoudini.so.3.4.7.44914


       --------- beginning of /dev/log/system
    04-28 21:44:46.063 450-470/? I/BootReceiver: Copying /data/tombstones/tombstone_03 to DropBox (SYSTEM_TOMBSTONE)
    04-28 21:44:46.063 450-13973/? W/ActivityManager:   Force finishing activity com.artandwords.thoughtoftheday/.activities.DisplayThoughtActivity
    04-28 21:44:46.073 145-862/? E/IMGSRV: :0: PVRDRMOpen: TP3, ret = 75
    04-28 21:44:46.093 450-13973/? E/JavaBinder: !!! FAILED BINDER TRANSACTION !!!
    04-28 21:44:46.093 450-483/? W/InputDispatcher: channel '21edd9e8 com.artandwords.thoughtoftheday/com.artandwords.thoughtoftheday.activities.main.MainActivity (server)' ~ Consumer closed input channel or an error occurred.  events=0x9
    04-28 21:44:46.093 450-483/? E/InputDispatcher: channel '21edd9e8 com.artandwords.thoughtoftheday/com.artandwords.thoughtoftheday.activities.main.MainActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
    04-28 21:44:46.093 155-13945/? W/TimedEventQueue: Event 25 was not found in the queue, already cancelled?
    04-28 21:44:46.093 155-3134/? W/AudioFlinger: session id 324 not found for pid 155
    04-28 21:44:46.103 450-450/? W/InputDispatcher: Attempted to unregister already unregistered input channel '21edd9e8 com.artandwords.thoughtoftheday/com.artandwords.thoughtoftheday.activities.main.MainActivity (server)'
    04-28 21:44:46.103 450-755/? I/WindowState: WIN DEATH: Window{21b33a28 u0 com.artandwords.thoughtoftheday/com.artandwords.thoughtoftheday.activities.DisplayThoughtActivity}
    04-28 21:44:46.103 450-13973/? W/ActivityManager: Exception thrown during pause
       android.os.TransactionTooLargeException
           at android.os.BinderProxy.transact(Native Method)
           at android.app.ApplicationThreadProxy.schedulePauseActivity(ApplicationThreadNative.java:642)
           at com.android.server.am.ActivityStack.startPausingLocked(ActivityStack.java:1007)
           at com.android.server.am.ActivityStack.finishActivityLocked(ActivityStack.java:3905)
           at com.android.server.am.ActivityStack.finishActivityLocked(ActivityStack.java:3837)
           at com.android.server.am.ActivityManagerService.handleAppCrashLocked(ActivityManagerService.java:8588)
           at com.android.server.am.ActivityManagerService.makeAppCrashingLocked(ActivityManagerService.java:8465)
           at com.android.server.am.ActivityManagerService.crashApplication(ActivityManagerService.java:9170)
           at com.android.server.am.ActivityManagerService.handleApplicationCrashInner(ActivityManagerService.java:8699)
           at com.android.server.am.NativeCrashListener$NativeCrashReporter.run(NativeCrashListener.java:86)
    04-28 21:44:46.103 450-450/? I/WindowState: WIN DEATH: Window{21edd9e8 u0 com.artandwords.thoughtoftheday/com.artandwords.thoughtoftheday.activities.main.MainActivity}
    04-28 21:44:46.103 450-636/? I/WindowState: WIN DEATH: Window{21be0690 u0 com.artandwords.thoughtoftheday/com.artandwords.thoughtoftheday.activities.DisplayThoughtActivity}
    04-28 21:44:46.113 450-13973/? I/WindowManager: computeScreenConfigurationLocked() Enter {1.15 ?mcc?mnc ?locale ?layoutDir ?swdp ?wdp ?hdp ?density ?lsize ?long ?orien ?uimode ?night ?touch ?keyb/?/? ?nav/?}
    04-28 21:44:46.113 450-13973/? I/WindowManager: dw=1200, dh=1920
    04-28 21:44:46.113 450-13973/? I/WindowManager: appWidth=1200, appHeight=1848
    04-28 21:44:46.113 450-13973/? I/WindowManager: tempdm=DisplayMetrics{density=1.5, width=1200, height=1848, scaledDensity=1.5, xdpi=221.201, ydpi=220.591}
    04-28 21:44:46.113 450-13973/? I/WindowManager: dm=DisplayMetrics{density=1.5, width=1200, height=1848, scaledDensity=1.5, xdpi=221.201, ydpi=220.591}, ro.product.device=ME302C
    04-28 21:44:46.113 450-13973/? I/WindowManager: getConfigDisplayWidth=1200, getConfigDisplayHeight=1810
    04-28 21:44:46.113 450-13973/? I/WindowManager: screenWidthDp=800, screenHeightDp=1206
    04-28 21:44:46.113 450-13973/? I/WindowManager: computeScreenConfigurationLocked() Leave {1.15 ?mcc?mnc ?locale ?layoutDir sw800dp w800dp h1206dp 240dpi xlrg port ?uimode ?night finger -keyb/v/h -nav/h}
    04-28 21:44:46.113 450-13973/? I/ActivityManager: Restarting because process died: ActivityRecord{21ab1f80 u0 com.artandwords.thoughtoftheday/.activities.main.MainActivity}
    04-28 21:44:46.113 450-13973/? W/ActivityManager: Exception when starting activity com.artandwords.thoughtoftheday/.activities.main.MainActivity
       android.os.DeadObjectException
           at android.os.BinderProxy.transact(Native Method)
           at android.app.ApplicationThreadProxy.scheduleLaunchActivity(ApplicationThreadNative.java:730)
           at com.android.server.am.ActivityStack.realStartActivityLocked(ActivityStack.java:733)
           at com.android.server.am.ActivityStack.startSpecificActivityLocked(ActivityStack.java:840)
           at com.android.server.am.ActivityStack.resumeTopActivityLocked(ActivityStack.java:1790)
           at com.android.server.am.ActivityStack.resumeTopActivityLocked(ActivityStack.java:1449)
           at com.android.server.am.ActivityStack.startPausingLocked(ActivityStack.java:1058)
           at com.android.server.am.ActivityStack.finishActivityLocked(ActivityStack.java:3905)
           at com.android.server.am.ActivityStack.finishActivityLocked(ActivityStack.java:3837)
           at com.android.server.am.ActivityManagerService.handleAppCrashLocked(ActivityManagerService.java:8588)
           at com.android.server.am.ActivityManagerService.makeAppCrashingLocked(ActivityManagerService.java:8465)
           at com.android.server.am.ActivityManagerService.crashApplication(ActivityManagerService.java:9170)
           at com.android.server.am.ActivityManagerService.handleApplicationCrashInner(ActivityManagerService.java:8699)
           at com.android.server.am.NativeCrashListener$NativeCrashReporter.run(NativeCrashListener.java:86)
    04-28 21:44:46.123 450-13973/? W/ContextImpl: Calling a method in the system process without a qualified user: android.app.ContextImpl.startService:1396 com.android.server.am.ActivityStack.sendActivityBroadcastLocked:4923 com.android.server.am.ActivityStack.removeActivityFromHistoryLocked:4089 com.android.server.am.ActivityStack.removeHistoryRecordsForAppLocked:4346 com.android.server.am.ActivityManagerService.handleAppDiedLocked:3163
    04-28 21:44:46.123 450-13973/? I/ActivityManager: Start proc com.artandwords.thoughtoftheday for activity com.artandwords.thoughtoftheday/.activities.main.MainActivity: pid=13975
    </unknown>

    Edit 1 :

    Still investigating and entered FFmpeg.java to the method loadBinary while debugging, which code I’ll paste below and the line making the crash is switch (CpuArchHelper.getCpuArch())

    @Override
    public void loadBinary(FFmpegLoadBinaryResponseHandler ffmpegLoadBinaryResponseHandler) throws FFmpegNotSupportedException
    String cpuArchNameFromAssets = null ;
    switch (CpuArchHelper.getCpuArch())
    case x86 :
    Log.i("Loading FFmpeg for x86 CPU") ;
    cpuArchNameFromAssets = "x86" ;
    break ;
    case ARMv7 :
    Log.i("Loading FFmpeg for armv7 CPU") ;
    cpuArchNameFromAssets = "armeabi-v7a" ;
    break ;
    case NONE :
    throw new FFmpegNotSupportedException("Device not supported") ;

    if (!TextUtils.isEmpty(cpuArchNameFromAssets)) {
       ffmpegLoadLibraryAsyncTask = new FFmpegLoadLibraryAsyncTask(context, cpuArchNameFromAssets, ffmpegLoadBinaryResponseHandler);
       ffmpegLoadLibraryAsyncTask.execute();
    } else {
       throw new FFmpegNotSupportedException("Device not supported");
    }

    I’ll keep on investigating...

    Edit 2 :

    Further debugging has just lead me to the exact line where app crashes, and it’s CpuArchHelper.java from FFmpeg library :

    The line causing the crash is the next :

    String archInfo = cpuNativeArchHelper.cpuArchFromJNI();

    and I cannot even go inside cpuArchFromJNI() with F7 as it just crashes.

    package com.github.hiteshsondhi88.libffmpeg;

    import android.os.Build;

    class CpuArchHelper {

       static CpuArch getCpuArch() {
           Log.d("Build.CPU_ABI : " + Build.CPU_ABI);
           // check if device is x86 or x86_64
           if (Build.CPU_ABI.equals(getx86CpuAbi()) || Build.CPU_ABI.equals(getx86_64CpuAbi())) {
               return CpuArch.x86;
           } else {
               // check if device is armeabi
               if (Build.CPU_ABI.equals(getArmeabiv7CpuAbi())) {
                   ArmArchHelper cpuNativeArchHelper = new ArmArchHelper();
                   String archInfo = cpuNativeArchHelper.cpuArchFromJNI();
                   // check if device is arm v7
                   if (cpuNativeArchHelper.isARM_v7_CPU(archInfo)) {
                       // check if device is neon
                       return CpuArch.ARMv7;
                   }
                   // check if device is arm64 which is supported by ARMV7
               } else if (Build.CPU_ABI.equals(getArm64CpuAbi())) {
                   return CpuArch.ARMv7;
               }
           }
           return CpuArch.NONE;
       }

       static String getx86CpuAbi() {
           return "x86";
       }

       static String getx86_64CpuAbi() {
           return "x86_64";
       }

       static String getArm64CpuAbi() {
           return "arm64-v8a";
       }

       static String getArmeabiv7CpuAbi() {
           return "armeabi-v7a";
       }
    }

    This is ArmArchHelper.java class :

    package com.github.hiteshsondhi88.libffmpeg;

    class ArmArchHelper {
       static {
           System.loadLibrary("ARM_ARCH");
       }

       native String cpuArchFromJNI();

       boolean isARM_v7_CPU(String cpuInfoString) {
           return cpuInfoString.contains("v7");
       }

       boolean isNeonSupported(String cpuInfoString) {
           // check cpu arch for loading correct ffmpeg lib
           return cpuInfoString.contains("-neon");
       }

    }
  • Matomo Celebrates 15 Years of Building an Open-Source & Transparent Web Analytics Solution

    30 juin 2022, par Matthieu Aubry — About, Community
    &lt;script type=&quot;text/javascript&quot;&gt;<br />
           if ('function' === typeof window.playMatomoVideo){<br />
           window.playMatomoVideo(&quot;brand&quot;, &quot;#brand&quot;)<br />
           } else {<br />
           document.addEventListener(&quot;DOMContentLoaded&quot;, function() { window.playMatomoVideo(&quot;brand&quot;, &quot;#brand&quot;); });<br />
           }<br />
      &lt;/script&gt;

    Fifteen years ago, I realised that people (myself included) were increasingly integrating the internet into their everyday lives, and it was clear that it would only expand in the future. It was an exciting new world, but the amount of personal data shared online, level of tracking and lack of security was a growing concern. Google Analytics was just launched then and was already gaining huge traction – so data from millions of websites started flowing into Google’s database, creating what was then the biggest centralised database about people worldwide and their actions online.

    So as a young engineering student, I decided we needed to build an open source and transparent solution that could help make the internet more secure and private while still providing organisations with powerful insights. I aimed to create a win-win solution for businesses and their digital consumers.

    And in 2007, I started developing Matomo with the help from Scott Switzer and Jennifer Langdon (who offered me an internship and support).   

    All thanks to the Matomo Community

    We have reached significant milestones and made major changes over the last 15 years, but we wouldn’t be where we are today without the Matomo Community.

    So I would like to celebrate and thank the hundreds of volunteer developers who have donated their time to develop Matomo, the thousands of contributors who provided feedback to improve Matomo, the countless supportive forum members, our passionate team of 40 at Matomo, the numerous translators who have translated Matomo and the 1.5 million websites that choose Matomo as their analytics platform.

    Matomo's Birthday
    Team Meetup in Paris in 2012

    Matomo has been a community effort built on the shoulders of many, and we will continue to work for you. 

    So let’s look at some milestones we have achieved over the last 15 years.

    Looking back on milestones in our timeline

    2007

    • Birth of Matomo
    • First alpha version released

    2008

    • Release first public 0.1.0 version

    2009

    • 50,000 websites use Matomo

    2010

    • Matomo first stable 1.0.0 released
    • Mobile app launched

    2011

    • Released Ecommerce Analytics, Custom Variables, First Party Cookies

    • Released Privacy control features (first of many privacy features to come !)

    2012

    • Released Log Analytics feature
    • 1 Million Downloads !
    • 300,000 websites worldwide use Matomo

    2013

    • Matomo is now available in 50 languages !
    • Matomo brand redesign

    2016

    2017

    • Launched Matomo Cloud service 
    • Released Multi Channel Conversion Attribution Premium Feature, Custom Reports Premium Feature, Login Saml Premium Feature, WooCommerceAnalytics Premium Feature and Heatmap & Session Recording Premium Feature 

    2018

    2019

    2020

    2021

    • 1,000,000 websites worldwide use Matomo
    • including 30,000 active Matomo for WordPress installations
    • Released SEO Web Vitals, Advertising Conversion Export and Tracking Spam Prevention feature

    2022

    • Released WP Statistics to Matomo importer

    Our efforts continue

    While we’ve seen incredible growth over the years, our work doesn’t stop there. In fact, we’re only just getting started.

    Today over 55% of the internet continues to use privacy-threatening web analytics solutions, while 1.5% uses Matomo. So there are still great strides to be made to create a more private internet, and joining the Matomo Community is one way to support this movement.

    There are many ways to get involved too, such as :

    So what comes next for Matomo ?

    The future of Matomo is approachable, powerful and flexible. We’re strengthening the customers’ voice, expanding our resources internally (we’re continuously hiring !) and conducting rigorous customer research to craft a tool that balances usability and functionality.

    I look forward to the next 15 years and seeing what the future holds for Matomo and our community.

  • WebVTT as a W3C Recommendation

    1er janvier 2014, par silvia

    Three weeks ago I attended TPAC, the annual meeting of W3C Working Groups. One of the meetings was of the Timed Text Working Group (TT-WG), that has been specifying TTML, the Timed Text Markup Language. It is now proposed that WebVTT be also standardised through the same Working Group.

    How did that happen, you may ask, in particular since WebVTT and TTML have in the past been portrayed as rival caption formats ? How will the WebVTT spec that is currently under development in the Text Track Community Group (TT-CG) move through a Working Group process ?

    I’ll explain first why there is a need for WebVTT to become a W3C Recommendation, and then how this is proposed to be part of the Timed Text Working Group deliverables, and finally how I can see this working between the TT-CG and the TT-WG.

    Advantages of a W3C Recommendation

    TTML is a XML-based markup format for captions developed during the time that XML was all the hotness. It has become a W3C standard (a so-called “Recommendation”) despite not having been implemented in any browsers (if you ask me : that’s actually a flaw of the W3C standardisation process : it requires only two interoperable implementations of any kind – and that could be anyone’s JavaScript library or Flash demonstrator – it doesn’t actually require browser implementations. But I digress…). To be fair, a subpart of TTML is by now implemented in Internet Explorer, but all the other major browsers have thus far rejected proposals of implementation.

    Because of its Recommendation status, TTML has become the basis for several other caption standards that other SDOs have picked : the SMPTE’s SMPTE-TT format, the EBU’s EBU-TT format, and the DASH Industry Forum’s use of SMPTE-TT. SMPTE-TT has also become the “safe harbour” format for the US legislation on captioning as decided by the FCC. (Note that the FCC requirements for captions on the Web are actually based on a list of features rather than requiring a specific format. But that will be the topic of a different blog post…)

    WebVTT is much younger than TTML. TTML was developed as an interchange format among caption authoring systems. WebVTT was built for rendering in Web browsers and with HTML5 in mind. It meets the requirements of the <track> element and supports more than just captions/subtitles. WebVTT is popular with browser developers and has already been implemented in all major browsers (Firefox Nightly is the last to implement it – all others have support already released).

    As we can see and as has been proven by the HTML spec and multiple other specs : browsers don’t wait for specifications to have W3C Recommendation status before they implement them. Nor do they really care about the status of a spec – what they care about is whether a spec makes sense for the Web developer and user communities and whether it fits in the Web platform. WebVTT has obviously achieved this status, even with an evolving spec. (Note that the spec tries very hard not to break backwards compatibility, thus all past implementations will at least be compatible with the more basic features of the spec.)

    Given that Web browsers don’t need WebVTT to become a W3C standard, why then should we spend effort in moving the spec through the W3C process to become a W3C Recommendation ?

    The modern Web is now much bigger than just Web browsers. Web specifications are being used in all kinds of devices including TV set-top boxes, phone and tablet apps, and even unexpected devices such as white goods. Videos are increasingly omnipresent thus exposing deaf and hard-of-hearing users to ever-growing challenges in interacting with content on diverse devices. Some of these devices will not use auto-updating software but fixed versions so can’t easily adapt to new features. Thus, caption producers (both commercial and community) need to be able to author captions (and other video accessibility content as defined by the HTML5 element) towards a feature set that is clearly defined to be supported by such non-updating devices.

    Understandably, device vendors in this space have a need to build their technology on standardised specifications. SDOs for such device technologies like to reference fixed specifications so the feature set is not continually updating. To reference WebVTT, they could use a snapshot of the specification at any time and reference that, but that’s not how SDOs work. They prefer referencing an officially sanctioned and tested version of a specification – for a W3C specification that means creating a W3C Recommendation of the WebVTT spec.

    Taking WebVTT on a W3C recommendation track is actually advantageous for browsers, too, because a test suite will have to be developed that proves that features are implemented in an interoperable manner. In summary, I can see the advantages and personally support the effort to take WebVTT through to a W3C Recommendation.

    Choice of Working Group

    FAIK this is the first time that a specification developed in a Community Group is being moved into the recommendation track. This is something that has been expected when the W3C created CGs, but not something that has an established process yet.

    The first question of course is which WG would take it through to Recommendation ? Would we create a new Working Group or find an existing one to move the specification through ? Since WGs involve a lot of overhead, the preference was to add WebVTT to the charter of an existing WG. The two obvious candidates were the HTML WG and the TT-WG – the first because it’s where WebVTT originated and the latter because it’s the closest thematically.

    Adding a deliverable to a WG is a major undertaking. The TT-WG is currently in the process of re-chartering and thus a suggestion was made to add WebVTT to the milestones of this WG. TBH that was not my first choice. Since I’m already an editor in the HTML WG and WebVTT is very closely related to HTML and can be tested extensively as part of HTML, I preferred the HTML WG. However, adding WebVTT to the TT-WG has some advantages, too.

    Since TTML is an exchange format, lots of captions that will be created (at least professionally) will be in TTML and TTML-related formats. It makes sense to create a mapping from TTML to WebVTT for rendering in browsers. The expertise of both, TTML and WebVTT experts is required to develop a good mapping – as has been shown when we developed the mapping from CEA608/708 to WebVTT. Also, captioning experts are already in the TT-WG, so it helps to get a second set of eyes onto WebVTT.

    A disadvantage of moving a specification out of a CG into a WG is, however, that you potentially lose a lot of the expertise that is already involved in the development of the spec. People don’t easily re-subscribe to additional mailing lists or want the additional complexity of involving another community (see e.g. this email).

    So, a good process needs to be developed to allow everyone to contribute to the spec in the best way possible without requiring duplicate work. How can we do that ?

    The forthcoming process

    At TPAC the TT-WG discussed for several hours what the next steps are in taking WebVTT through the TT-WG to recommendation status (agenda with slides). I won’t bore you with the different views – if you are keen, you can read the minutes.

    What I came away with is the following process :

    1. Fix a few more bugs in the CG until we’re happy with the feature set in the CG. This should match the feature set that we realistically expect devices to implement for a first version of the WebVTT spec.
    2. Make a FSA (Final Specification Agreement) in the CG to create a stable reference and a clean IPR position.
    3. Assuming that the TT-WG’s charter has been approved with WebVTT as a milestone, we would next bring the FSA specification into the TT-WG as FPWD (First Public Working Draft) and immediately do a Last Call which effectively freezes the feature set (this is possible because there has already been wide community review of the WebVTT spec) ; in parallel, the CG can continue to develop the next version of the WebVTT spec with new features (just like it is happening with the HTML5 and HTML5.1 specifications).
    4. Develop a test suite and address any issues in the Last Call document (of course, also fix these issues in the CG version of the spec).
    5. As per W3C process, substantive and minor changes to Last Call documents have to be reported and raised issues addressed before the spec can progress to the next level : Candidate Recommendation status.
    6. For the next step – Proposed Recommendation status – an implementation report is necessary, and thus the test suite needs to be finalized for the given feature set. The feature set may also be reduced at this stage to just the ones implemented interoperably, leaving any other features for the next version of the spec.
    7. The final step is Recommendation status, which simply requires sufficient support and endorsement by W3C members.

    The first version of the WebVTT spec naturally has a focus on captioning (and subtitling), since this has been the dominant use case that we have focused on this far and it’s the part that is the most compatibly implemented feature set of WebVTT in browsers. It’s my expectation that the next version of WebVTT will have a lot more features related to audio descriptions, chapters and metadata. Thus, this seems a good time for a first version feature freeze.

    There are still several obstacles towards progressing WebVTT as a milestone of the TT-WG. Apart from the need to get buy-in from the TT-WG, the TT-CG, and the AC (Adivisory Committee who have to approve the new charter), we’re also looking at the license of the specification document.

    The CG specification has an open license that allows creating derivative work as long as there is attribution, while the W3C document license for documents on the recommendation track does not allow the creation of derivative work unless given explicit exceptions. This is an issue that is currently being discussed in the W3C with a proposal for a CC-BY license on the Recommendation track. However, my view is that it’s probably ok to use the different document licenses : the TT-WG will work on WebVTT 1.0 and give it a W3C document license, while the CG starts working on the next WebVTT version under the open CG license. It probably actually makes sense to have a less open license on a frozen spec.

    Making the best of a complicated world

    WebVTT is now proposed as part of the recharter of the TT-WG. I have no idea how complicated the process will become to achieve a W3C WebVTT 1.0 Recommendation, but I am hoping that what is outlined above will be workable in such a way that all of us get to focus on progressing the technology.

    At TPAC I got the impression that the TT-WG is committed to progressing WebVTT to Recommendation status. I know that the TT-CG is committed to continue developing WebVTT to its full potential for all kinds of media-time aligned content with new kinds already discussed at FOMS. Let’s enable both groups to achieve their goals. As a consequence, we will allow the two formats to excel where they do : TTML as an interchange format and WebVTT as a browser rendering format.