Recherche avancée

Sur d’autres sites (6452)

• Trouble automating concatination (merging) of VOB files from DVD with FFMPEG

  2 juillet 2020, par Randy

  I have a library of decrypted DVDs, which all have their video in a series of VOB files within the usual VIDEO_TS folder. I wondered if I could use FFMPEG to combine them into a single MPEG files. So first I found this (this assumes 2 VOB files) from an old non-stack exchange post, and it works...

  


  ffmpeg -i "concat:VTS_01_1.VOB|VTS_01_2.VOB" -f DVD 


  


  ffmpeg complains sometimes about possible missing timestamps, but I've not seen any issues in the video, audio, or synchronization. This works too with slightly different complaints

  


  ffmpeg -i "concat:VTS_01_1.VOB|VTS_01_2.VOB" -f mpeg -c copy output.mpeg


  


  So what I'd like to do is make a windows (1) batch file to create the "concat" string, after analyzing a TS_VIDEO directory. Well as it turns out, putting a "|" character in a string is a tall order. (even escaping it doesn't works as expected.) So I looked up the ffmpeg docs on the "concat" subject, and they suggest using a list of files stored in a text file, like this...

  


  file 'VTS_01_1.VOB'
file 'VTS_01_2.VOB' (etc...)

  


  Then using a call to FFMPEG like this...

  


  ffmpeg -f concat -safe 0 -i mylist.txt -c copy output.mpg


  


  Well I tried that and it didn't work very well. After the first VOB file, I was getting continuous warnings about buffer underflow and time stamps, and the usually fast concatenation process slowed to a creep. Warnings typically looked like this...

  


  


  [mpeg @ 00000185e32b4200] buffer underflow st=1 bufi=1466 size=1998

  


  [mpeg @ 00000185e32b4200] Non-monotonous DTS in output stream 0:1 ;
previous : 328415794, current : 9265348 ; changing to 328415795. This may
result in incorrect timestamps in the output file.

  


  


  So can anyone suggest a method that WORKS as well as my first example, but taking the list of files from an input text file ?

  


• How do I alter my FFMPEG command to make my HTTP Live Streams more efficient ?

  11 juillet 2019, par Robert

  I want to reduce the muxing overhead when creating .ts files using FFMPEG.

  Im using FFMPEG to create a series of transport stream files used for HTTP live streaming.

  ./ffmpeg -i myInputFile.ismv \
  
           -vcodec copy \
  
           -acodec copy \
  
           -bsf h264_mp4toannexb \
  
           -map 0 \
  
           -f segment \
  
           -segment_time 10\
  
           -segment_list_size 999999 \
  
           -segment_list output/myVarientPlaylist.m3u8 \
  
           -segment_format mpegts \
  
           output/myAudioVideoFile-%04d.ts

  My input is in ismv format and contains a video and audio stream :

  Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 320x240, 348 kb/s, 29.97 tbr, 10000k tbn, 59.94 tbc
  
  Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 63 kb/s

  There is an issues related to muxing that is causing a large amout of overhead to be added to the streams. This is how the issue was described to me for the audio :

  

  So for a given aac stream, the overhead will be 88% (since 200 bytes will map to 2 x 188 byte packets).

  For video, the iframe packets are quite large, so they translate nicely into .ts packets, however, the diffs can be as small as an audio packet, therefore they suffer from the same issue.

  The solution is to combine several aac packets into one larger stream before packaging them into .ts. Is this possible out of the box with FFMPEG ?

• Anomalie #4097 (En cours) : bug HTTPS dans la fonction url_de_base() sur certains serveurs mal con...

  14 février 2018, par Pierre-Aurélien Georges

  Bonjour,

  voici le contexte : le serveur web de mon hébergeur est mal configuré (et je n’ai malheureusement pas réussi à leur faire corriger le problème). Le site web [1] est accessible aussi bien en HTTP qu’en HTTPS, mais en allant sur /ecrire/ ?exec=info je vois que le serveur ne renseigne ni la variable $_SERVER[’HTTPS’] ni la variable $_SERVER["SCRIPT_URI"], et à vrai dire lorsque je compare sur ce serveur un phpinfo() en HTTP et un phpinfo() en HTTPS je vois qu’il y n’a strictement AUCUNE différence entre les deux, et qu’il est donc totalement impossible de savoir (côté serveur) si la requête a été faite en HTTP ou en HTTPS.

  Dans ce contexte bien précis, le code de la fonction url_de_base() situé dans /ecrire/inc/utils.php pose problème, car il se base sur le contenu de ces deux variables $_SERVER[’HTTPS’] et $_SERVER["SCRIPT_URI"] pour choisir entre HTTP et HTTPS et il ne tient absolument pas compte du contenu du champ META, ce qui dans mon cas est bien dommage car j’y ai mis l’url en https:...

  La conséquence de tout ceci est qu’en HTTPS cela entraîne des problèmes d’affichage d’images et de CSS qui ne sont pas bien appliqués, cf. [2]. Sur ce forum, vous verrez que je ne suis pas le seul à avoir affaire à un serveur mal configuré de la sorte, et que nous sommes plusieurs à avoir ce même problème. La solution de bricolage donnée par un des participants du forum est de rajouter dans /config/mes_options.php les deux lignes suivantes :
  

  $_SERVER[’HTTPS’] = "on" ;
  $_SERVER[’SERVER_PORT’]=’443’ ;
  

  
  Ca fonctionne, certes, et c’est donc ce que j’ai fait pour mon site, mais c’est vraiment du bricolage et c’était pas évident de trouver cette astuce !

  Pour faire plus propre et plus simple, serait-il possible à l’avenir de modifier le code de url_de_base() pour qu’en l’absence de ces deux variables $_SERVER[’HTTPS’] et $_SERVER["SCRIPT_URI"], la fonction aille regarder dans META si c’est du http ou du https qui y est renseigné (au lieu de mettre forcément du http) ? En effet, lorsque META commence par "https://" ça veut dire que le serveur gère le HTTPS, et donc s’il ne renseigne pas les variables HTTPS et SCRIPT_URI et bien dans le doute mieux vaut générer des url de base en "https://" plutôt qu’en "http://" car si cette url de base se retrouve mentionnée au sein d’un fichier html ou css, et que le fichier en question est demandé en HTTP, ce n’est pas grave s’il contient des ressources en HTTPS, alors que le contraire pose problème (ne pas mettre de ressources en HTTP au sein d’une page en HTTPS !)