Recherche avancée

Sur d’autres sites (13014)

• WebVTT Discussions at FOMS

  18 décembre 2013, par silvia

  At the recent FOMS (Foundations of Open Media Software and Standards) Developer Workshop, we had a massive focus on WebVTT and the state of its feature set. You will find links to summaries of the individual discussions in the FOMS Schedule page. Here are some of the key results I went away with.

  1. WebVTT Regions

  The key driving force for improvements to WebVTT continues to be the accurate representation of CEA608/708 captioning. As part of that drive, we’ve introduced regions (the CEA708 “window” concept) to WebVTT. WebVTT regions satisfy multiple requirements of CEA608/708 captions :

  1. support for rollup captions
  2. support for background color and border color on a group of cues independent of the background color of the individual cue
  3. possibility to move a group of cues from one location on screen to a different
  4. support to specify an anchor point and a growth direction for cues when their text size changes
  5. support for specifying a fixed number of lines to be rendered
  6. possibility to specify which region is rendered in front of which other one when regions overlap

  While WebVTT regions enable us to satisfy all of the above points, the specification isn’t actually complete yet and some of the above needs aren’t satisfied yet.

  We have an open bug to move a region elsewhere. A first discussion at FOMS seemed to to indicate that we’ll have to add syntax for updating a region at a particular time and thus give region definitions a way to be valid only for a certain time frame. I can imagine that the region definitions that we have in the header of the WebVTT file now would have an implicitly defined time frame from the start to the end of the file, but can be overruled by a re-definition anywhere within the WebVTT file. That redefinition needs to provide a start and end time.

  We registered a bug to add specifying the width and height of regions (and possibly of cues) by em (i.e. by multiples of the largest character in a font). This should allow us to have the region grow/shrink around the region anchor point with a change of font size by script or a user. em specifications should also be applied to cues – that matches the column count of CEA708/608 better.

  When regions overlap, the original region extension spec already suggested a “layer” cue setting. It will be easy to add it.

  Another change that we will ultimately need is the “scroll” setting : we will need to introduce support for scrolling text down or from left-to-right or right-to-left, e.g. vertical scrolling text seems to be used in some Chinese caption use cases.

  2. Unify Rendering Approach

  The introduction of regions created a second code path in the rendering spec with some duplication. At FOMS we discussed if it was possible to unify that. The suggestion is to render all cues into a region. Those that are not part of a region would be rendered into an anonymous region that covers the complete viewport. There may be some consequences to this, e.g. cue settings should be usable across all cues, no matter whether or not part of a region, and avoiding cue overlap may need to be done within regions.

  Here’s a rough outline of the path of the new rendering algorithm :

  (1) Render the regions :

  Specified Region	Anonymous Region
  Render values as given :	Render following values :
  width lines regionanchor viewportanchor scroll	100% videoheight/lineheight 0,0 0,0 none

  (2) Render the cues :

  • Create a cue box and put it in its region (anonymous if none given).
  • Calculate position & size of cue box from cue settings (position, line, size).
  • Calculate position of cue text inside cue box from remaining cue settings (vertical, align).

  3. Vertical Features

  WebVTT includes vertical rendering, both right-to-left and left-to-right. However, regions are not defined for vertical. Eventually, we’re going to have to look at the vertical features of WebVTT with more details and figure out whether the spec is working for them and what real-world requirements we have missed. We hope we can get some help from users in countries where vertically rendered captions/subtitles are the norm.

  4. Best Practices

  Some of he WebVTT users at FOMS suggested it would be advantageous to start a list of “best practices” for how to author captions with WebVTT. Example recommendations are :

  • Use line numbers only to position cues from top or bottom of viewport. Don’t use otherwise.
  • Note that when the user increases the fontsize in rollup captions and thus introduces new line breaks, your cues will roll by faster because the number of lines of a rollup is fixed.
  • Make sure to use &lrm ; and &rlm ; UTF-8 markers to control the directionality of your text.

  It would be nice if somebody started such a document.

  5. Non-caption use cases

  Instead of continuing to look back and improve our support of captions/subtitles in WebVTT, one session at FOMS also went ahead and looked forward to other use cases. The following requirements came out of this :

  5.1 Preview Thumbnails

  A common use case for timed data is the use of preview thumbnails on the navigation bar of videos. A native implementation of preview thumbnails would allow crawlers and search engines to have a standardised way of extracting timed images for media files, so introduction of a new @kind value “thumbnails” was suggested.

  The content of a “thumbnails” cue could be any of :

  • an image URL
  • a sprite URL to a single image
  • a spatial & temporal media fragment URL to a media resource
  • base64 encoded image (data URI)
  • an iframe offset to the media resource

  The suggestion is to allow anything that would work in a img @src attribute as value in a cue of @kind=”thumbnails”. Responsive images might also be useful for a track of @kind=”thumbnails”. It may even be possible to define an inband thumbnail track based on the track of @kind=”thumbnails”. Such cues should also work in the JavaScript track API.

  5.2 Chapter markers

  There is interest to put richer content than just a chapter title into chapter cues. Often, chapters consist of a title, text and and image. The text is not so important, but the image is used almost everywhere that chapters are used. There may be a need to extend chapter cue content with images, similar to what a @kind=”thumbnails” track offers.

  The conclusion that we arrived at was that we need to make @kind=”thumbnails” work first and then look at using the learnings from that to extend @kind=”chapters”.

  5.3 Inband tracks for live video

  A difficult topic was opened with the question of how to transport text tracks in live video. In live captioning, end times are never created for cues, but are implied by the start time of the next cue. This is a use case that hasn’t been addressed in HTML5/WebVTT yet. An old proposal to allow a special end time value of “NEXT” was discussed and recommended for adoption. Also, there was support for the spec change that stops blocking loading VTT until all cues have been loaded.

  5.4 Cross-domain VTT loading

  A brief discussion centered around the fact that the spec disallows cross-domain loading of WebVTT files, but that no browser implements this. This needs to be discussion at the HTML WG level.

  6. Regions in live captioning

  The final topic that we discussed was how we could provide support for regions in live captioning.

  • The currently active region definitions will need to be come part of every header of every VTT file segment that HLS uses, so it’s available in case the cues in the segment file reference it.
  • “NEXT” in end time markers would make authoring of live captioned VTT files easier.
  • If the application wants to use 1 word at a time and doesn’t want to delay sending the word until the full cue is authored (e.g. in a Hangout type environment), we will need to introduce the concept of “cue continuation markers”, so we know that a cue could be extended with the next VTT file fragment.

  This is an extensive and impressive amount of discussion around WebVTT and a lot of new work to be performed in the future. I’m very grateful for all the people who have contributed to these discussions at FOMS and will hopefully continue to help get the specifications right.

• WebVTT Discussions at FOMS

  1er janvier 2014, par silvia

  At the recent FOMS (Foundations of Open Media Software and Standards) Developer Workshop, we had a massive focus on WebVTT and the state of its feature set. You will find links to summaries of the individual discussions in the FOMS Schedule page. Here are some of the key results I went away with.

  1. WebVTT Regions

  The key driving force for improvements to WebVTT continues to be the accurate representation of CEA608/708 captioning. As part of that drive, we’ve introduced regions (the CEA708 “window” concept) to WebVTT. WebVTT regions satisfy multiple requirements of CEA608/708 captions :

  1. support for rollup captions
  2. support for background color and border color on a group of cues independent of the background color of the individual cue
  3. possibility to move a group of cues from one location on screen to a different
  4. support to specify an anchor point and a growth direction for cues when their text size changes
  5. support for specifying a fixed number of lines to be rendered
  6. possibility to specify which region is rendered in front of which other one when regions overlap

  While WebVTT regions enable us to satisfy all of the above points, the specification isn’t actually complete yet and some of the above needs aren’t satisfied yet.

  We have an open bug to move a region elsewhere. A first discussion at FOMS seemed to to indicate that we’ll have to add syntax for updating a region at a particular time and thus give region definitions a way to be valid only for a certain time frame. I can imagine that the region definitions that we have in the header of the WebVTT file now would have an implicitly defined time frame from the start to the end of the file, but can be overruled by a re-definition anywhere within the WebVTT file. That redefinition needs to provide a start and end time.

  We registered a bug to add specifying the width and height of regions (and possibly of cues) by em (i.e. by multiples of the largest character in a font). This should allow us to have the region grow/shrink around the region anchor point with a change of font size by script or a user. em specifications should also be applied to cues – that matches the column count of CEA708/608 better.

  When regions overlap, the original region extension spec already suggested a “layer” cue setting. It will be easy to add it.

  Another change that we will ultimately need is the “scroll” setting : we will need to introduce support for scrolling text down or from left-to-right or right-to-left, e.g. vertical scrolling text seems to be used in some Chinese caption use cases.

  2. Unify Rendering Approach

  The introduction of regions created a second code path in the rendering spec with some duplication. At FOMS we discussed if it was possible to unify that. The suggestion is to render all cues into a region. Those that are not part of a region would be rendered into an anonymous region that covers the complete viewport. There may be some consequences to this, e.g. cue settings should be usable across all cues, no matter whether or not part of a region, and avoiding cue overlap may need to be done within regions.

  Here’s a rough outline of the path of the new rendering algorithm :

  (1) Render the regions :

  Specified Region	Anonymous Region
  Render values as given :	Render following values :
  width lines regionanchor viewportanchor scroll	100% videoheight/lineheight 0,0 0,0 none

  (2) Render the cues :

  • Create a cue box and put it in its region (anonymous if none given).
  • Calculate position & size of cue box from cue settings (position, line, size).
  • Calculate position of cue text inside cue box from remaining cue settings (vertical, align).

  3. Vertical Features

  WebVTT includes vertical rendering, both right-to-left and left-to-right. However, regions are not defined for vertical. Eventually, we’re going to have to look at the vertical features of WebVTT with more details and figure out whether the spec is working for them and what real-world requirements we have missed. We hope we can get some help from users in countries where vertically rendered captions/subtitles are the norm.

  4. Best Practices

  Some of he WebVTT users at FOMS suggested it would be advantageous to start a list of “best practices” for how to author captions with WebVTT. Example recommendations are :

  • Use line numbers only to position cues from top or bottom of viewport. Don’t use otherwise.
  • Note that when the user increases the fontsize in rollup captions and thus introduces new line breaks, your cues will roll by faster because the number of lines of a rollup is fixed.
  • Make sure to use &lrm ; and &rlm ; UTF-8 markers to control the directionality of your text.

  It would be nice if somebody started such a document.

  5. Non-caption use cases

  Instead of continuing to look back and improve our support of captions/subtitles in WebVTT, one session at FOMS also went ahead and looked forward to other use cases. The following requirements came out of this :

  5.1 Preview Thumbnails

  A common use case for timed data is the use of preview thumbnails on the navigation bar of videos. A native implementation of preview thumbnails would allow crawlers and search engines to have a standardised way of extracting timed images for media files, so introduction of a new @kind value “thumbnails” was suggested.

  The content of a “thumbnails” cue could be any of :

  • an image URL
  • a sprite URL to a single image
  • a spatial & temporal media fragment URL to a media resource
  • base64 encoded image (data URI)
  • an iframe offset to the media resource

  The suggestion is to allow anything that would work in a img @src attribute as value in a cue of @kind=”thumbnails”. Responsive images might also be useful for a track of @kind=”thumbnails”. It may even be possible to define an inband thumbnail track based on the track of @kind=”thumbnails”. Such cues should also work in the JavaScript track API.

  5.2 Chapter markers

  There is interest to put richer content than just a chapter title into chapter cues. Often, chapters consist of a title, text and and image. The text is not so important, but the image is used almost everywhere that chapters are used. There may be a need to extend chapter cue content with images, similar to what a @kind=”thumbnails” track offers.

  The conclusion that we arrived at was that we need to make @kind=”thumbnails” work first and then look at using the learnings from that to extend @kind=”chapters”.

  5.3 Inband tracks for live video

  A difficult topic was opened with the question of how to transport text tracks in live video. In live captioning, end times are never created for cues, but are implied by the start time of the next cue. This is a use case that hasn’t been addressed in HTML5/WebVTT yet. An old proposal to allow a special end time value of “NEXT” was discussed and recommended for adoption. Also, there was support for the spec change that stops blocking loading VTT until all cues have been loaded.

  5.4 Cross-domain VTT loading

  A brief discussion centered around the fact that the spec disallows cross-domain loading of WebVTT files, but that no browser implements this. This needs to be discussion at the HTML WG level.

  6. Regions in live captioning

  The final topic that we discussed was how we could provide support for regions in live captioning.

  • The currently active region definitions will need to be come part of every header of every VTT file segment that HLS uses, so it’s available in case the cues in the segment file reference it.
  • “NEXT” in end time markers would make authoring of live captioned VTT files easier.
  • If the application wants to use 1 word at a time and doesn’t want to delay sending the word until the full cue is authored (e.g. in a Hangout type environment), we will need to introduce the concept of “cue continuation markers”, so we know that a cue could be extended with the next VTT file fragment.

  This is an extensive and impressive amount of discussion around WebVTT and a lot of new work to be performed in the future. I’m very grateful for all the people who have contributed to these discussions at FOMS and will hopefully continue to help get the specifications right.

• How to set CONFIG_PATH in Heroku buildpack

  3 avril 2015, par johnklawlor

  Before I elaborate on the problem, I should let you know that I’ve successfully installed ffmpegthumbnailer on heroku’s bash (heroku run bash).

  I’m trying to build ffmpegthumbnailer using a custom Heroku buildpack I’ve written, but when I run ./configure && make install in the bin/compile buildpack file, ffmpegthumbnailer tells me that it can’t find the ffmpeg libs (util, format, codec, scale) and suggest that I set the PKG_CONFIG_PATH. So I set the PKG_CONFIG_PATH and it still can’t seem to find the libraries.

  I’ve tried setting the PKG_CONFIG_PATH every which way. echo export, export, directly set it via PKG_CONFIG_PATH=/app... I’ve always set it inline with the .configure command. I even set PKG_CONFIG_PATH as a heroku config var, and tried to acces it via the ENV_DIR variable that’s passed into the buildpack as the third parameter, but I soon realized that I was simply setting a variable PKG_CONFIG_PATH to the contents of the file called PKG_CONFIG_PATH, i.e. I was setting PKG_CONFIG_PATH=/app/vendor..., which I’ve already done !! None of these have worked. Also, as you can see in the compile file and the log, echo $PKG_CONFIG_PATH prints the correct path.

  What more debugging can i do ? What is going on ?

  Below is my bin/compile buildpack file, and the log after I deploy my app to heroku.

  #!/bin/sh
  
  
  
  indent() {
  
    sed -u 's/^/       /'
  
  }
  
  
  
  echo "-----> Install ffmpeg-thumbnailer"
  
  BUILD_DIR=$1
  
  VENDOR_DIR="vendor"
  
  DOWNLOAD_URL="https://ffmpegthumbnailer.googlecode.com/files/ffmpegthumbnailer-2.0.8.tar.gz"
  
  
  
  echo "DOWNLOAD_URL = " $DOWNLOAD_URL | indent
  
  
  
  cd $BUILD_DIR
  
  mkdir -p $VENDOR_DIR
  
  cd $VENDOR_DIR
  
  curl -L --silent $DOWNLOAD_URL | tar xz
  
  cd ffmpegthumbnailer-2.0.8/
  
  export PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/app/vendor/ffmpeg/lib/pkgconfig/"
  
  echo $PKG_CONFIG_PATH
  
  ./configure --prefix /app/vendor/ffmpegthumbnailer && make install
  
  
  
  echo "exporting PATH and LIBRARY_PATH" | indent
  
  PROFILE_PATH="$BUILD_DIR/.profile.d/ffmpeg-thumbnailer.sh"
  
  mkdir -p $(dirname $PROFILE_PATH)
  
  echo 'export PATH="$PATH:vendor/ffmpeg-thumbnailer/bin"' >> $PROFILE_PATH
  
  echo 'export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:vendor/ffmpeg-thumbnailer/lib"' >> $PROFILE_PATH

  And my heroku deployment log...

  Fetching repository, done.
  
  Counting objects: 5, done.
  
  Delta compression using up to 2 threads.
  
  Compressing objects: 100% (3/3), done.
  
  Writing objects: 100% (3/3), 311 bytes, done.
  
  Total 3 (delta 2), reused 0 (delta 0)
  
  
  
  -----> Fetching custom git buildpack... done
  
  -----> Multipack app detected
  
  =====> Downloading Buildpack: https://github.com/shunjikonishi/heroku-buildpack-ffmpeg
  
  =====> Detected Framework: ffmpeg
  
  -----> Install ffmpeg
  
         DOWNLOAD_URL =  http://flect.github.io/heroku-binaries/libs/ffmpeg.tar.gz
  
         exporting PATH and LIBRARY_PATH
  
  =====> Downloading Buildpack: https://github.com/johnklawlor/heroku-buildpack-ffmpeg-thumbnailer
  
  =====> Detected Framework: ffmpeg
  
  -----> Install ffmpeg-thumbnailer
  
  HERE COMES PKG_CONFIG!
  
  /app/vendor/ffmpeg/lib/pkgconfig
  
         DOWNLOAD_URL =  https://ffmpegthumbnailer.googlecode.com/files/ffmpegthumbnailer-2.0.8.tar.gz
  
  /app/vendor/ffmpeg/lib/pkgconfig
  
  checking for a BSD-compatible install... /usr/bin/install -c
  
  checking whether build environment is sane... yes
  
  checking for a thread-safe mkdir -p... /bin/mkdir -p
  
  checking for gawk... no
  
  checking for mawk... mawk
  
  checking whether make sets $(MAKE)... yes
  
  checking for g++... g++
  
  checking whether the C++ compiler works... yes
  
  checking for C++ compiler default output file name... a.out
  
  checking for suffix of executables...
  
  checking whether we are cross compiling... no
  
  checking for suffix of object files... o
  
  checking whether we are using the GNU C++ compiler... yes
  
  checking whether g++ accepts -g... yes
  
  checking for style of include used by make... GNU
  
  checking dependency style of g++... gcc3
  
  checking build system type... x86_64-unknown-linux-gnu
  
  checking host system type... x86_64-unknown-linux-gnu
  
  checking how to print strings... printf
  
  checking for gcc... gcc
  
  checking whether we are using the GNU C compiler... yes
  
  checking whether gcc accepts -g... yes
  
  checking for gcc option to accept ISO C89... none needed
  
  checking dependency style of gcc... gcc3
  
  checking for a sed that does not truncate output... /bin/sed
  
  checking for grep that handles long lines and -e... /bin/grep
  
  checking for egrep... /bin/grep -E
  
  checking for fgrep... /bin/grep -F
  
  checking for ld used by gcc... /usr/bin/ld
  
  checking if the linker (/usr/bin/ld) is GNU ld... yes
  
  checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
  
  checking the name lister (/usr/bin/nm -B) interface... BSD nm
  
  checking whether ln -s works... yes
  
  checking the maximum length of command line arguments... 1572864
  
  checking whether the shell understands some XSI constructs... yes
  
  checking whether the shell understands "+="... yes
  
  checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
  
  checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
  
  checking for /usr/bin/ld option to reload object files... -r
  
  checking for objdump... objdump
  
  checking how to recognize dependent libraries... pass_all
  
  checking for dlltool... no
  
  checking how to associate runtime and link libraries... printf %s\n
  
  checking for ar... ar
  
  checking for archiver @FILE support... @
  
  checking for strip... strip
  
  checking for ranlib... ranlib
  
  checking command to parse /usr/bin/nm -B output from gcc object... ok
  
  checking for sysroot... no
  
  checking for mt... mt
  
  checking if mt is a manifest tool... no
  
  checking how to run the C preprocessor... gcc -E
  
  checking for ANSI C header files... yes
  
  checking for sys/types.h... yes
  
  checking for sys/stat.h... yes
  
  checking for stdlib.h... yes
  
  checking for string.h... yes
  
  checking for memory.h... yes
  
  checking for strings.h... yes
  
  checking for inttypes.h... yes
  
  checking for stdint.h... yes
  
  checking for unistd.h... yes
  
  checking for dlfcn.h... yes
  
  checking for objdir... .libs
  
  checking if gcc supports -fno-rtti -fno-exceptions... no
  
  checking for gcc option to produce PIC... -fPIC -DPIC
  
  checking if gcc PIC flag -fPIC -DPIC works... yes
  
  checking if gcc static flag -static works... yes
  
  checking if gcc supports -c -o file.o... yes
  
  checking if gcc supports -c -o file.o... (cached) yes
  
  checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
  
  checking whether -lc should be explicitly linked in... no
  
  checking dynamic linker characteristics... GNU/Linux ld.so
  
  checking how to hardcode library paths into programs... immediate
  
  checking whether stripping libraries is possible... yes
  
  checking if libtool supports shared libraries... yes
  
  checking whether to build shared libraries... yes
  
  checking whether to build static libraries... yes
  
  checking how to run the C++ preprocessor... g++ -E
  
  checking for ld used by g++... /usr/bin/ld -m elf_x86_64
  
  checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
  
  checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
  
  checking for g++ option to produce PIC... -fPIC -DPIC
  
  checking if g++ PIC flag -fPIC -DPIC works... yes
  
  checking if g++ static flag -static works... yes
  
  checking if g++ supports -c -o file.o... yes
  
  checking if g++ supports -c -o file.o... (cached) yes
  
  checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
  
  checking dynamic linker characteristics... (cached) GNU/Linux ld.so
  
  checking how to hardcode library paths into programs... immediate
  
  checking for special C compiler options needed for large files... no
  
  checking for _FILE_OFFSET_BITS value needed for large files... no
  
  checking whether make supports nested variables... yes
  
  checking for ANSI C header files... (cached) yes
  
  checking for inttypes.h... (cached) yes
  
  checking for sys/stat.h... (cached) yes
  
  checking whether /usr/bin/ld -m elf_x86_64 accepts --as-needed... yes
  
  checking for pkg-config... /usr/bin/pkg-config
  
  checking pkg-config is at least version 0.9.0... yes
  
  checking for FFMPEG... no
  
  configure: error: Package requirements (libavutil libavformat libavcodec >= 52.26.0 libswscale) were not met:
  
  
  
  No package 'libavutil' found
  
  No package 'libavformat' found
  
  No package 'libavcodec' found
  
  No package 'libswscale' found
  
  
  
  Consider adjusting the PKG_CONFIG_PATH environment variable if you
  
  installed software in a non-standard prefix.
  
  
  
  Alternatively, you may set the environment variables FFMPEG_CFLAGS
  
  and FFMPEG_LIBS to avoid the need to call pkg-config.
  
  See the pkg-config man page for more details.
  
         exporting PATH and LIBRARY_PATH
  
  =====> Downloading Buildpack: https://github.com/heroku/heroku-buildpack-ruby