Sur d’autres sites (9792)

• Transcoding fMP4 to HLS while writing on iOS using FFmpeg

  12 juillet 2017, par bclymer

  TL ;DR

  I want to convert fMP4 fragments to TS segments (for HLS) as the fragments are being written using FFmpeg on an iOS device.

  Why ?

  I’m trying to achieve live uploading on iOS while maintaining a seamless, HD copy locally.

  What I’ve tried

  1. Rolling AVAssetWriters where each writes for 8 seconds, then concatenating the MP4s together via FFmpeg.

     What went wrong - There are blips in the audio and video at times. I’ve identified 3 reasons for this.

     1) Priming frames for audio written by the AAC encoder creating gaps.

     2) Since video frames are 33.33ms long, and audio frames 0.022ms long, it’s possible for them to not line up at the end of a file.

     3) The lack of frame accurate encoding present on Mac OS, but not available for iOS Details Here

  2. FFmpeg muxing a large video only MP4 file with raw audio into TS segments. The work was based on the Kickflip SDK

     What Went Wrong - Every once in a while an audio only file would get uploaded, with no video whatsoever. Never able to reproduce it in-house, but it was pretty upsetting to our users when they didn’t record what they thought they did. There were also issues with accurate seeking on the final segments, almost like the TS segments were incorrectly time stamped.

  What I’m thinking now

  Apple was pushing fMP4 at WWDC this year (2016) and I hadn’t looked into it much at all before that. Since an fMP4 file can be read, and played while it’s being written, I thought that it would be possible for FFmpeg to transcode the file as it’s being written as well, as long as we hold off sending the bytes to FFmpeg until each fragment within the file is finished.

  However, I’m not familiar enough with the FFmpeg C API, I only used it briefly within attempt #2.

  What I need from you

  1. Is this a feasible solution ? Is anybody familiar enough with fMP4 to know if I can actually accomplish this ?
  2. How will I know that AVFoundation has finished writing a fragment within the file so that I can pipe it into FFmpeg ?
  3. How can I take data from a file on disk, chunk at a time, pass it into FFmpeg and have it spit out TS segments ?

• Anomalie #920 (En cours) : Gérer les logos comme des documents

  27 décembre 2019, par b b

  Je pense qu’on peut fermer suite à cette rafale de modifs, non ?

  r24348 r24349 r24351 r24355 r24356

  https://zone.spip.net/trac/spip-zone/changeset/116119/
  https://zone.spip.net/trac/spip-zone/changeset/116123/
  https://zone.spip.net/trac/spip-zone/changeset/116237/
  https://zone.spip.net/trac/spip-zone/changeset/116143/

• nomenclature #3469 (Nouveau) : Étendre la balise #URL_PAGE à tout objet éditorial

  6 juin 2015, par tetue tetue

  La balise #URL_PAGE affiche actuellement la page fabriquée par le squelette passé en paramètre : http://www.spip.net/fr_article4630.html

  Cette balise pourrait être étendue aux objets éditoriaux de SPIP, de façon à être utilisée facilement, sans paramètre, pour lier explicitement la page SPIP, ce qui est utile pour les objets possédant par ailleurs une URL qui leur est propre, tel que les sites.

  #URL_PAGE afficherait l’url de la page dédiée à l’objet, c’est-à-dire la page générée via le squelette homonyme (sans nécessiter de le passer en paramètre), si ce skel existe, sinon rien.

  Par exemple :

  - dans une boucle SITES, #URL_PAGE afficherait l’url de la page fabriquée par le skel « site » — au lieu de l’actuel [(#ID_SYNDIC|generer_url_entitesite)] anciennement (#ID_SYNDIC, trop barbare — tandis que #URL_FORUM affiche l’url de la page où est affiché le message
  - dans une boucle DOCUMENTS, #URL_PAGE afficherait l’url de la page fabriquée par le skel « document », s’il existe, tandis que #URL_DOCUMENT affiche l’url du fichier multimédia
  - idem avec les FORUMS
  - dans une boucle SYNDIC_ARTICLES, #URL_PAGE n’afficherait rien, car le squelette « article_syndic » n’existe pas
  - dans une boucle ARTICLES, #URL_PAGE afficherait l’url de la page fabriquée par le skel « article », comme #URL_ARTICLE
  - etc.

  Il ne s’agit pas tant qu’une évolution, puisque l’affichage de toutes ces URLs est déjà possible, que d’une homogénéisation et simplification de la nomenclature. Mieux vaut écrire #URL_PAGE que [(#ID_SYNDIC|generer_url_entitesite)], n’est-ce pas ;)