Recherche avancée

Sur d’autres sites (6194)

• ffmpeg to dvb-c. Need some advices

  12 octobre 2017, par pentarhh

  I’d like to get some advices about ffmpeg transcoding and broadcasting it to DVB-C environment.
  Have a server, based on Linux with external GPUs based on Nvidia P4000. Target of this machine is getting live streams at HLS, then it transcode files to multicast UDP. After transcoding multicast TS gets to receiver (Sumavision EMR 3.0), then modulates into DVB-C with QAM-card for next transmission to fiber.

  So, there is a strange trouble. In IPTV such stream have no visible troubles. Analyzing TS, saw an errors with PCR accuracy (>500 ms ’cause of pseudo-CBR) and very rare discontinuity errors, that could be based on source errors.
  Then I take it to Sumavision and apply inbound parameters (just remultiplexing this stream with making loyal reference, buffer size values and CBR output values). Analyzer sees no problem, after putting in QAM-modulator customize output streams, such as PSI/SI tables, frequency, symbol rate etc.

  After I see the result at some test TVs. First one shows this channel great, with no visible troubles (no artefacts, no asynchronous sound). Second TV has a problem of video, it looks like a lost frames. Sometimes sound interrupts for a milliseconds. But there is no freezes
  ’Cause of ETR 101 290 passes well, may be this model of TV decodes this service incorrect. Example of video record is here.

  Here is the code of ffmpeg. May be, I missed some common parameters, that may get the output is better for such tuners. Can you see it’s alright ?

  sudo -u nobody ffmpeg -threads 0 -v warning -re -hwaccel cuvid -hwaccel_device 2 -c:v h264_cuvid -deint 0 -i http://x.x.x.x/playlist.m3u8 -bsf:v h264_mp4toannexb -map 0:0 -map 0:1 -vcodec h264_nvenc -gpu 2 -cbr true -sc_threshold 0 -filter:v scale_npp=960:540:interp_algo=lanczos -vprofile baseline -b:v 1000k -bufsize 1400k -maxrate 1400k -minrate 900k -force_key_frames 1 -g 50 -bf 0 -refs 1 -r 25 -strict experimental -c:a aac -b:a 64K -af aresample=44100 -ac 2 -flags -global_header -f segment -segment_format mpegts -segment_time 10 /path1/segment-1507744758-%06d.ts -map 0:0 -map 0:1 -vcodec h264_nvenc -gpu 2 -cbr true -sc_threshold 0 -vprofile high -b:v 8000k -bufsize 400k -maxrate 9000k -minrate 7200k -force_key_frames 1 -g 50 -bf 2 -refs 1 -r 25 -strict experimental -c:a aac -b:a 192K -af aresample=44100 -ac 2 -flags -global_header -f tee 
  
  [f=segment:segment_format=mpegts:segment_time=10]/path2/segment-1507744758-%06d.ts|[f=mpegts:muxrate=9333k:mpegts_pmt_start_pid=0xB4A:mpegts_start_pid=0xB4B]'udp://y.y.y.y:1234?buffer_size=0&overrun_nonfatal_option=1&pkt_size=1316&ttl=15'

• Evolution #4037 (Nouveau) : Éviter les doublons lors de l’ajout d’un document distant

  1er novembre 2017, par Franck D

  Bonjour :-)
  Lorsque l’on télécharge un document depuis "internet" pour le mettre dans un article, il va dans la médiathèque automatiquement (super pratique) !
  Par contre, si l’on fait la création d’un autre article et que l’on télécharge à nouveau ce même documents via la même url, cela télécharge le document en double !

  Alors que l’idéal serait que la médiathèque affiche un message comme quoi ce document est déjà dans la médiathèque sous le numéro xxxxx
  Cela éviterait de prendre de la place sur le serveur pour rien, et comme le numéro s’afficherait, il serait simple pour un rédacteur de le retrouver dans la médiathèque

  Nous avons le cas par exemple sur contrib, un zip est télécharger plusieurs fois dans la médiathèque car il est dans plusieurs articles parfois (traduction ou évolution du plug, qui demande une nouvelle doc)

  Après l’inconvénient que je vois, c’est dans le cas ou même si l’url est identique, que le doc est vraiment différent, cela doit êtes des cas rare, mais possible que parfois des gens mettent des documents à jours en ligne mais avec le même nom de doc, donc, c’est pour cela que je ne sais pas si c’est vraiment une bonne idée n’y même possible, car sauf à savoir la taille des documents pour comparaison, il est possible que cela soit bloquant parfois :-(
  Franck

• Evolution #4102 : Ordre des inclures dans cache/charger_plugins_options.php

  23 février 2018, par RastaPopoulos ♥

  Je l’ai déjà dit juste avant, il faut absolument qu’il continue d’y avoir un fichier avec le même ordre puisqu’on y met des pipelines, des variables globales (GLOBALS[’z_blocs’] par ex mais il y en a d’autres) qui DOIVENT être dans l’ordre actuel avec ceux qui nécessitent en dernier pour pouvoir passer après.

  Le cas des define() qui doivent être en tout premier est le seul cas particulier où ça doit être avant, alors on ne va pas prendre ça comme cas principal sur lequel se baser. C’est celui là le cas rare et surtout qui ne concerne absolument que les define().

  Dans tous les autres cas, ceux qui veulent surcharger doivent se trouver après, pas avant.

  Et donc il faudrait plutôt un pipeline au tout début, dédié à ce cas des define(), ou pas que, mais où on sait qu’on est au tout début de SPIP, avant même les inclusions des fichiers. Un pipeline "initialisation" en fait, c’est même plus générique que "pre_options" comme je disais avant.