Recherche avancée

Sur d’autres sites (7014)

• Anomalie #3647 : #INTRODUCTION + propre sous PHP7

  26 février 2016, par Ivan Lewkowitz

  Hello,

  - Pour la première balise [(#INTRODUCTION800|liens_ouvrants|propre)], je viens de retester et elle fonctionne comme ça. L’article a changé depuis la dernière fois, ce qui me laisse penser que le contenu a pu influencer. A vérifier… mais bon.

  - Regarde plus en détail la deuxième balise que j’utilise en survol dans une boucle où je liste les 3 derniers articles de certaines rubriques.
  

  [(#TITRE|supprimer_numero|rtrim’. ’)]

  Dans les trois résultats qui s’affichent, le premier et le troisième fonctionnent mais pas le deuxième (voir capture ci joint).
  Plus précisément, le deuxième affiche l’intro en survol tant que je coupe à 290 : [(#INTRODUCTION290|supprimer_tags|attribut_html)]
  mais si je passe à [(#INTRODUCTION291|supprimer_tags|attribut_html)] (ou plus), ça ne marche plus.

  Les deux autres intro au dessus et en dessous marchent tout le temps !

  

  Le code du texte de l’article qui déconne est :
  

  Le petit fils de Kim Il-sung est à la tête d’un régime militarisé dont l’arme nucléaire constitue le gage de sa survie. Toujours aux prises avec des difficultés alimentaires il comprend mal la logique de profit qui sous tend les investissements étrangers.

  
  

  Après le test nucléaire nord-coréen du 6 janvier, le scénario des réactions internationales qui se répète depuis 2006 n’a pas varié, sauf que, pour la dernière expérience en date, Pyongyang affirme avoir franchi le cap technologique de la fusion ce qui ajoute beaucoup à la sidération internationale, la puissance théorique d’un tel engin pouvant être 1000 fois supérieure à celle d’une bombe A classique. Mais pour l’heure, les premières réponses de la communauté internationale sont symétriques de celles qui suivirent le dernier test de 2013.

  Rien de spécial dans le texte, à part les accents de la langue française. Comme tu peux le voir sur l’image 2, j’ai même des intros contenant du chinois qui s’affichent sans problème.

  

• avformat/matroskaenc : Write duration early during mkv_write_header (Rev #3)

  17 juillet 2016, par softworkz

  avformat/matroskaenc : Write duration early during mkv_write_header (Rev #3)
  Rev #2 : Fixes doubled header writing, checked FATE running without errors
  
  Rev #3 : Fixed coding style
  This commit addresses the following scenario :
  we are using ffmpeg to transcode or remux mkv (or something else) to mkv. The result is being streamed on-the-fly to an HTML5 client (streaming starts while ffmpeg is still running). The problem here is that the client is unable to detect the duration because the duration is only written to the mkv at the end of the transcoding/remoxing process. In matroskaenc.c, the duration is only written during mkv_write_trailer but not during mkv_write_header.
  The approach :
  FFMPEG is currently putting quite some effort to estimate the durations of source streams, but in many cases the source stream durations are still left at 0 and these durations are nowhere mapped to or used for output streams. As much as I would have liked to deduct or estimate output durations based on input stream durations - I realized that this is a hard task (as Nicolas already mentioned in a previous conversation). It would involve changes to the duration calculation/estimation/deduction for input streams and propagating these durations to output streams or the output context in a correct way.
  
  So I looked for a simple and small solution with better chances to get accepted. In webmdashenc.c I found that a duration is written during write_header and this duration is taken from the streams’ metadata, so I decided for a similar approach.
  And here’s what it does :
  At first it is checking the duration of the AVFormatContext. In typical cases this value is not set, but : It is set in cases where the user has specified a recording_time or an end_time via the -t or -to parameters.
  
  Then it is looking for a DURATION metadata field in the metadata of the output context (AVFormatContext::metadata). This would only exist in case the user has explicitly specified a metadata DURATION value from the command line.
  
  Then it is iterating all streams looking for a "DURATION" metadata (this works unless the option "-map_metadata -1" has been specified) and determines the maximum value.
  
  The precendence is as follows : 1. Use duration of AVFormatContext - 2. Use explicitly specified metadata duration value - 3. Use maximum (mapped) metadata duration over all streams.
  To test this :
  1. With explicit recording time :
  
  ffmpeg -i file :"src.mkv" -loglevel debug -t 01:38:36.000 -y "dest.mkv"
  2. Take duration from metadata specified via command line parameters :
  
  ffmpeg -i file :"src.mkv" -loglevel debug -map_metadata -1 -metadata Duration="01:14:33.00" -y "dest.mkv"
  3. Take duration from mapped input metadata :
  
  ffmpeg -i file :"src.mkv" -loglevel debug -y "dest.mkv"
  Regression risk :
  Very low IMO because it only affects the header while ffmpeg is still running. When ffmpeg completes the process, the duration is rewritten to the header with the usual value (same like without this commit).
  Signed-off-by : SoftWorkz <softworkz@hotmail.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/matroskaenc.c

• Force GStreamer for IOS to use ffmpeg library outside of the framework

  24 avril 2014, par Michelle Cannon

  Gstreamer 1.0 for IOS is delivered in a static framework, the source to build the framework is around 1.2g , this framework is huge and tries to provide for any decoding server scenario you may have. Trouble is it tries to do to much and IMHO not enough thought was put into the IOS port.

  Here’s the problem we have an application that uses the GSTreamer avdec_h264 plugin for displaying an RTP over UDP stream . This works rather well. recently we were required to do some special recording functions so we introduced an api that had its own version of ffmpeg. Gstreamer has Libav compiled into the framework. When we place our api into the application with the gst_IOS_RESTICTED_PLUGINS disabled the code runs fine when we introduce the GStreamer.framework into the application code similar to that shown below fails with a protocol not found error.

  The problem is that the internal version of libav seems to disable all the protocols that ffmpeg supplies. because GSTreamer uses its own custom AVIO callback based on ffmpeg pipe protocol.

  According to Gstreamer support that has been somewhat helpful

  ) Add a new recipe with the libav version you want to use and disable the build of the internal libav in gst-libav-1.0 with :
  configure_options = ’—with-system-libav’

  You might need to comment out this part to prevent libav being packaged in the framewiork or make sure that your libav recipe creates these files in the correct place to include them in the framework :

  42 for f in [’libavcodec’, ’libavformat’, ’libavutil’, ’libswscale’] :
  43 for ext in [’.a’, ’.la’] :
  44 path = os.path.join(’lib’, f + ext)
  45 self.files_plugins_codecs_restricted_devel.append(path)

  2) Update libav submodule gst-libav to use the correct version you need.

  https://bugs.freedesktop.org/show_bug.cgi?id=77399

  The first method didn’t work , the recipe kept getting overwritten even after applying a patch for a bug fix that was made as result of this bug report.

  And I have no idea how to do the second method. Which is what I’d like some help with.

  Has anyone with GStreamer 1.0 for iOS

  1) Built the get-libav plugin against an external to to the framework set of ffmpeg static libs (.a)

  2) built the internal libav to allow for RTP , UDP and TCP protocols, or written a custom AVIO callback using the FFPipe protocol.

  3) just managed to somehow get the below code working with GStreamer.

  I don’t ask many questions, I’ve kind of implemented all kinds of encoders/decoders using ffmpeg , lib555 and a few hardware decoders. But this GStreamer issue is causing me more sleepless nights than I’ve had in a long time.

  AVFormatContext * avctx;
  
  avctx = avformat_alloc_context();
  
  
  
  av_register_all();
  
  avformat_network_init();
  
  avcodec_register_all();
  
  avdevice_register_all();
  
  
  
  
  
  
  
  // Set the RTSP Options
  
  AVDictionary *opts = 0;
  
  
  
  av_dict_set(&opts, "rtsp_transport", "udp", 0);
  
  
  
  
  
  int err = 0;
  
  err = avformat_open_input(&avctx, "rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov", NULL, &opts);
  
  av_dict_free(&opts);
  
  if (err) {
  
      NSLog(@"Error: Could not open stream: %d", err);
  
      char errbuf[400];
  
      av_strerror(err,errbuf,400);
  
      NSLog(@"%s failed with error %s","avformat_open_input",errbuf);
  
  
  
  
  
  
  
  }
  
  else {
  
      NSLog(@"Opened stream");
  
  }
  
  
  
  err = avformat_find_stream_info(avctx, NULL);
  
  if( err < 0)
  
  {
  
      char errbuf[400];
  
      av_strerror(err,errbuf,400);
  
      NSLog(@"%s failed with error %s","avformat_find_stream_info",errbuf);
  
      return ;
  
  }else {
  
       NSLog(@"found stream info");
  
  }

  }