Recherche avancée

Sur d’autres sites (6424)

• http: Stop reading after receiving the whole file for non-chunked transfers

  11 août 2014, par Martin Storsjö

  http: Stop reading after receiving the whole file for non-chunked transfers
  Previously this logic was only used if the server didn’t
  
  respond with Connection : close, but use it even for that case,
  
  if the server response is non-chunked.
  Originally the http code has relied on Connection : close to close
  
  the socket when the file/stream is received - the http protocol
  
  code just kept reading from the socket until the socket was closed.
  
  In f240ed18 we added a check for the file size, because some
  
  http servers didn’t respond with Connection : close (and wouldn’t
  
  close the socket) even though we requested it, which meant that the
  
  http protocol blocked for a long time at the end of files, waiting
  
  for a socket level timeout.
  When reading over tls, trying to read at the end of the connection,
  
  when the peer has closed the connection, can produce spurious (but
  
  harmless) warnings. Therefore always voluntarily stop reading when
  
  the specified file size has been received, if not using a chunked
  
  transfer encoding. (For chunked transfers, we already return 0
  
  as soon as we get the chunk header indicating end of stream.)
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavformat/http.c

• Anomalie #4495 (Nouveau) : migration 3.2.7 vers 3.3.0

  24 mai 2020, par josiane aletto

  test 1-
  j’ai installée en local un site qui était en SPIP 3.2.7 [24473] pour le migrer en SPIP 3.3.0-dev [24578].
  fichier mesoptions.php avec
  

  <span class="CodeRay"><span class="predefined">define</span>(<span class="string"><span class="delimiter">'</span><span class="content">_IMG_MAX_HEIGHT</span><span class="delimiter">'</span></span>,<span class="integer">1200</span>); <span class="comment">// largeur en pixels</span>
  <span class="predefined">define</span>(<span class="string"><span class="delimiter">'</span><span class="content">_IMG_MAX_WIDTH</span><span class="delimiter">'</span></span>, <span class="integer">1024</span>);  <span class="comment">// hauteur en pixels</span>
  <span class="predefined">define</span>(<span class="string"><span class="delimiter">'</span><span class="content">_IMG_MAX_SIZE</span><span class="delimiter">'</span></span>,  <span class="integer">650</span>);   <span class="comment">// taille en kilo-octets</span>
  </span>
  Télécharger

  
  Des logos de taille superieure a _IMG_MAX_SIZE’, 650 ne sont plus dans IMG Pas non plus dans logo_erreur non plus.
  par exemple rubon3 : 1630 × 648 pixels
  Plugins :
  Adaptive Images 1.9.2 -
  Agenda 3.26.0 -
  API de vérification 1.8.1 - stable
  Centre image 0.10.4 - dev
  Couleur de rubrique 2.3.8
  Facteur 3.6.2 - stable
  Formidable 3.34.3 - stable
  Insérer Modèles 1.3.3 - stable
  Massicot 0.8.1 -
  Mini Calendrier 2.4.1 - stable
  oEmbed 2.0.10 - stable
  Owl Carousel 1.0.18
  Carousel responsive avec support du multi-touch.
  Palette 4.0.7
  pdf.js 0.6.3
  Picto mod avec FontAwesome 2.1.0
  Saisies pour formulaires 3.11.1
  SPIP Bonux 3.4.6
  YAML 2.0.10
  test2
  Pour mieux voir J’ai recommencé installation /migration en désinstallant le plugin massicot et en le supprimant du repertoire plugin et en mettant dans mes_options.php
  define(’_IMG_MAX_HEIGHT’,800) ; // largeur en pixels
  define(’_IMG_MAX_WIDTH’, 500) ; // hauteur en pixels
  define(’_IMG_MAX_SIZE’, 400) ; // taille en kilo-octets

  je constate ; que les logos de taille >400Ko sont présent mais retaillé, rubon3 qui avait 1630 × 648 pixels a maintenant à 500 × 199 pixels 221 ko dans logo/IMG alors qu’il n’ y a pas massicot.
  si je supprime ce rubon3 par logo de la rubrique et télécharge l’image originale j’obtiens une image retaillé avec du noir en plus. mais si je clique dessus l’image est retaillée mais ok et elle est bien en 500*199 dans IMG sans le noir.

  • les images migrées ont bien gardées leurs dimensions*.

  test3
  je telecharge le logo rubon3 de 1630 × 648 pixels comme un document d’un article —> il est enregistré directement en 500 × 199 pixels 221 ko . Ce mécanisme a changé, en mieux, car dans la version 3.2 j’avais un message "Les images doivent obligatoirement faire moins de 650 ko (ce fichier fait 847.5 ko)".

• Changing container using FFMPEG produces NAL unit error

  28 avril 2015, par Mazze

  Background :

  My current videofile is put in a Linux based system that streams content (RTP) to other users. I’m filming and sending the content to the server after I change the and make sure the encoding is correct I stumble upon issues.

  I’ve tried doing this using ffmpeg, however the system I’m injecting this file in won’t recognize it and stream it to another device.

  I’m doing all the transcoding and such on a Windows system

  C:\Users\mazdak\Documents\Projects\ffmpeg\bin>ffmpeg -y -i input.mp4 -pix_fmt yuv420p -c:v libx264 -profile:v main -level:v 4.1 -color_range 0 -colorspace bt709 -x264opts colorprim=bt709:transfer=bt709:bframes=1 -an output.mkv

  Error :
  What I’m getting is

      StreamMedia exception ry: Unexpected NAL unit type: 9
  
      (...)
  
      StreamMedia exception ry: First media frame must be sync point

  Maybe I’m not preparing it for RTSP ? Is that the issue. Cause what I see is that the files that are able to stream are encoded using Gstreamer

  So I thought.. perhaps ffmpeg does not do that ? well let’s give gst-launch a try.
  I need pointers as to how to go about this.

  What I have :

  • OSSBuild of GStreamer
  • ffmpeg utils
  • input.mp4 - H264 Main profile L3.1 - Pixel format yuvj420p
  • Audio in container

  What I need (probably) :

  • output.mkv- H264 Main profile L4.1 - Pixel format yuv420p - RTP prepared (rtph264pay module)

  • Audio removed

  I have h264_analyze output from both the movie I filmed. From the movie that is successfully streamed, and the movies from my attempts with ffmpeg