Recherche avancée

Sur d’autres sites (13871)

• Cannot convert video file to audio file inside AWS lambda function using Node js

  21 février 2019, par Arun

  I cannot convert a video file into an audio file inside AWS lambda function using Node JS. While running my lambda function it doesn’t throw any error it executes without any error. But the audio file size is still 0 MB size. I am not able to find bugs or any issues in my code.

  Here is my code,

  const fs = require('fs');
  
  const childProcess = require('child_process');
  
  const AWS = require('aws-sdk');
  
  const path = require('path');
  
  AWS.config.update({
  
      region : 'us-east-2'
  
  });
  
  const s3 = new AWS.S3({apiVersion: '2006-03-01'});
  
  
  
  
  
  exports.handler = (event, context, callback) => {
  
      process.env.PATH = process.env.PATH + ':/tmp/';
  
      process.env['FFMPEG_PATH'] = '/tmp/ffmpeg';
  
      const BIN_PATH = process.env['LAMBDA_TASK_ROOT'];
  
      process.env['PATH'] = process.env['PATH'] + ':' + BIN_PATH;
  
  
  
      childProcess.exec(
  
          'cp /var/task/ffmpeg /tmp/.; chmod 755 /tmp/ffmpeg;',
  
          function (error, stdout, stderr) {
  
              if (error) {
  
                  console.log('Error occured',error);
  
              } else {
  
                  var ffmpeg = '/tmp/ffmpeg';
  
                  var createStream = fs.createWriteStream("/tmp/video.mp3");
  
                  createStream.end();
  
                  var params = {
  
                      Bucket: "test-bucket",
  
                      Key: event.Records[0].s3.object.key
  
                  };
  
                  s3.getObject(params, function(err, data) {
  
                      if (err) {
  
                          console.log("Error", err);
  
                      }
  
                      fs.writeFile("/tmp/vid.mp4", data.Body, function (err) {
  
                          if (err) console.log(err.code, "-", err.message);
  
                          return callback(err);
  
                      }, function() {
  
                          try {
  
                              var stats = fs.statSync("/tmp/vid.mp4");
  
                              console.log("size of the file1 ", stats["size"]);
  
                              try {
  
                                  console.log("Yeah");
  
                                  const inputFilename = "/tmp/vid.mp4";
  
                                  const mp3Filename = "/tmp/video.mp3";
  
                                  // // Convert the FLV file to an MP3 file using ffmpeg.
  
                                  const ffmpegArgs = [
  
                                      '-i', inputFilename,
  
                                      '-vn', // Disable the video stream in the output.
  
                                      '-acodec', 'libmp3lame', // Use Lame for the mp3 encoding.
  
                                      '-ac', '2', // Set 2 audio channels.
  
                                      '-q:a', '6', // Set the quality to be roughly 128 kb/s.
  
                                      mp3Filename,
  
                                  ];
  
                                  try {
  
                                      const process = childProcess.spawnSync(ffmpeg, ffmpegArgs);
  
                                      console.log("stdout ", process.stdout);
  
                                      console.log("stderr ", process.stderr);
  
                                      console.log("tmp files ");
  
                                      fs.readdir('/tmp/', (err, files) => {
  
                                          files.forEach(file => {
  
                                              var stats = fs.statSync(`/tmp/${file}`);
  
                                              console.log("size of the file2 ", stats["size"]);
  
                                            console.log(file);
  
                                          });
  
                                        });
  
  
  
                                  } catch (e) {
  
                                      console.log("error while converting video to audio ", e);
  
                                  }
  
  
  
                                  // return process;
  
                              } catch (e) {
  
                                  console.log(e);
  
                              }
  
                          } catch (e) {
  
                              console.log("file is not complete", e);
  
                          }
  
                      }, function () {
  
                          console.log("checking ");
  
                          var stats = fs.statSync("/tmp/video.mp3");
  
                          console.log("size of the file2 ", stats["size"]);
  
                      });
  
  
  
                      return callback(err);
  
                  });
  
              }
  
          }
  
      )
  
  }

  Code workflow

  First of all, I have downloaded ffmpeg binary exec file and put into my project directory. After that, I compressed my project and put it into the lambda function. This lambda function will be triggered whenever the new files are uploaded into an S3 bucket. I have checked /tmp/ storage files and the audio file .mp3 present but the size is 0 MB.

  Note

  And also, in my code the below is not calling or this part is not reaching. When I look into Cloudwatch logs I can’t see this console log messages. I don’t know why this function is not calling.

  function () {
  
          console.log("checking ");
  
          var stats = fs.statSync("/tmp/video.mp3");
  
          console.log("size of the file2 ", stats["size"]);
  
      });

  Please help me to find the solution of this issue. I have spent a lot of times to figure out this issue. But I am not able to find the solution. Any suggestions are welcome !!
  Thanks,

• avcodec/flac_parser : Fix off-by-one error

  6 octobre 2019, par Andreas Rheinhardt

  avcodec/flac_parser : Fix off-by-one error
  The flac parser uses a fifo to buffer its data. Consequently, when
  
  searching for sync codes of flac packets, one needs to take care of
  
  the possibility of wraparound. This is done by using an optimized start
  
  code search that works on each of the continuous buffers separately and
  
  by explicitly checking whether the last pre-wrap byte and the first
  
  post-wrap byte constitute a valid sync code.
  Moreover, the last MAX_FRAME_HEADER_SIZE - 1 bytes ought not to be searched
  
  for (the start of) a sync code because a header that might be found in this
  
  region might not be completely available. These bytes ought to be searched
  
  lateron when more data is available or when flushing.
  Unfortunately there was an off-by-one error in the calculation of the
  
  length to search of the post-wrap buffer : It was too large, because the
  
  calculation was based on the amount of bytes available in the fifo from
  
  the last pre-wrap byte onwards. This meant that a header might be
  
  parsed twice (once prematurely and once regularly when more data is
  
  available) ; it could also mean that an invalid header will be treated as
  
  valid (namely if the length of said invalid header is
  
  MAX_FRAME_HEADER_SIZE and the invalid byte that will be treated as the
  
  last byte of this potential header happens to be the right CRC-8).
  Should a header be parsed twice, the second instance will be the best child
  
  of the first instance ; the first instance's score will be
  
  FLAC_HEADER_BASE_SCORE - FLAC_HEADER_CHANGED_PENALTY ( = 3) higher than
  
  the second instance's score. So the frame belonging to the first
  
  instance will be output and it will be done as a zero length frame (the
  
  difference of the header's offset and the child's offset). This has
  
  serious consequences when flushing, as returning a zero length buffer
  
  signals to the caller that no more data will be output ; consequently the
  
  last frames not yet output will be dropped.
  Furthermore, a "sample/frame number mismatch in adjacent frames" warning
  
  got output when returning the zero-length frame belonging to the first
  
  header, because the child's sample/frame number of course didn't match
  
  the expected sample frame/number given its parent.
  filter/hdcd-mix.flac from the FATE-suite was affected by this (the last
  
  frame was omitted) which is the reason why several FATE-tests needed to
  
  be updated.
  Fixes ticket #5937.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavcodec/flac_parser.c
  • [DH] tests/fate/filter-audio.mak

• Anomalie #4543 : Accessibilité des chargements ajax (live regions)

  3 septembre 2020, par RastaPopoulos ♥

  En positionnant ces attributs, avec ces valeurs, sur des div englobantes, cela génère dans les lecteurs d’écran la lecture automatique des contenus qui ont été mis à jour.

  Certes la lecture peut être interrompue par l’utilisateur, mais cela revient, à mon avis à imposer quelque chose qui n’a pas été forcément souhaité. De cette manière le propriétaire du site impose une expérience différente aux utilisateurs de lecteur d’écran.

  Je ne suis pas sûr de comprendre : lancer la lecture des contenus mis à jour c’est bien très exactement ce qu’on cherchait à faire avec ces attributs il me semble. Donc ça fait bien ce qu’on cherche à faire. À la louche, je pense que 99% des utilisations de rechargement ajax SPIP (avec le critère ajax + des liens ".ajax" ou des forms) concernent parfaitement des cas avec une interaction donc un rechargement qui est explicitement demandé par l’utilisateurice : clic sur un lien qui recharge un bloc ajax OU clic sur un bouton qui recharge un formulaire en ajax. Ce n’est donc pas du tout quelque chose d’imposé et de forcé : l’utilisateurice demande une ressource (lien ajax) ou poste un formulaire (ajax) qui sont alors chargés dynamiquement SANS recharger toute la page : on veut donc bien effectivement que le lecteur d’écran se mette à relire le morceau qui vient d’être chargé !

  Ne pas utiliser ces attributs lorsqu’il n’y a pas d’interactions / rechargement ajax . Exemple sur un formulaire, cela n’a pas de sens : on rempli un form et puis on valide le form. A priori (si j’ai bien compris le fonctionnement) il n ’y a aucune raison d’utiliser de live region.

  Ces attributs sont sur des forms ajax, pas les forms non-ajax, non ? Quand on poste un formulaire ajax, alors seulement son bloc se recharge, et à l’intérieur de ce bloc, les contenus ont changé : des erreurs sont affichés, ou un message de retour final est ajouté, etc. C’est donc bien totalement voulu (l’utilisateurice a volontairement cliqué) et on veut que ça relise ce morceau puisque des contenus ont changé dedans, et souvent très important pour un formulaire (erreurs à corriger etc).

  Du coup je ne comprends pas leurs remarques : on a l’impression que tout ce qu’ils disent part du principe que ce sont des choses rechargées en arrière-plan par une volonté du dév (ce qui peut arriver dans 1% des cas, super rare), alors que non non, c’est bien à chaque fois un clic volontaire (lien ou bouton) de l’utilisateurice.