Recherche avancée

Sur d’autres sites (7692)

• ffmpeg file conversion AWS Lambda

  10 avril 2021, par eartoolbox

  I want a .webm file to be converted to a .wav file after it hits my S3 bucket. I followed this tutorial and tried to adapt it from my use case using the .webm -> .wav ffmpeg command described here.

  


  My AWS Lambda function generally works, in that when my .webm file hits the source bucket, it is converted to .wav and ends up in the destination bucket. However, the resulting file .wav is always 0 bytes (though the .webm not, including the appropriate audio). Did I adapt the code wrong ? I only changed the ffmpeg_cmd line from the first link.

  


  import json
import os
import subprocess
import shlex
import boto3

S3_DESTINATION_BUCKET = "hmtm-out"
SIGNED_URL_TIMEOUT = 60

def lambda_handler(event, context):

    s3_source_bucket = event['Records'][0]['s3']['bucket']['name']
    s3_source_key = event['Records'][0]['s3']['object']['key']

    s3_source_basename = os.path.splitext(os.path.basename(s3_source_key))[0]
    s3_destination_filename = s3_source_basename + ".wav"

    s3_client = boto3.client('s3')
    s3_source_signed_url = s3_client.generate_presigned_url('get_object',
        Params={'Bucket': s3_source_bucket, 'Key': s3_source_key},
        ExpiresIn=SIGNED_URL_TIMEOUT)
    
    ffmpeg_cmd = "/opt/bin/ffmpeg -i \"" + s3_source_signed_url + "\" -c:a pcm_f32le " + s3_destination_filename + " -"
    
    
    command1 = shlex.split(ffmpeg_cmd)
    p1 = subprocess.run(command1, stdout=subprocess.PIPE, stderr=subprocess.PIPE)

    resp = s3_client.put_object(Body=p1.stdout, Bucket=S3_DESTINATION_BUCKET, Key=s3_destination_filename)

    return {
        'statusCode': 200,
        'body': json.dumps('Processing complete successfully')
    }
 


  


• ffmpeg file conversion AWS Lamda

  10 avril 2021, par eartoolbox

  I want a .webm file to be converted to a .wav file after it hits my S3 bucket. I followed this tutorial and tried to adapt it from my use case using the .webm -> .wav ffmpeg command described here.

  


  My AWS Lambda function generally works, in that when my .webm file hits the source bucket, it is converted to .wav and ends up in the destination bucket. However, the resulting file .wav is always 0 bytes (though the .webm not, including the appropriate audio). Did I adapt the code wrong ? I only changed the ffmpeg_cmd line from the first link.

  


  import json
import os
import subprocess
import shlex
import boto3

S3_DESTINATION_BUCKET = "hmtm-out"
SIGNED_URL_TIMEOUT = 60

def lambda_handler(event, context):

    s3_source_bucket = event['Records'][0]['s3']['bucket']['name']
    s3_source_key = event['Records'][0]['s3']['object']['key']

    s3_source_basename = os.path.splitext(os.path.basename(s3_source_key))[0]
    s3_destination_filename = s3_source_basename + ".wav"

    s3_client = boto3.client('s3')
    s3_source_signed_url = s3_client.generate_presigned_url('get_object',
        Params={'Bucket': s3_source_bucket, 'Key': s3_source_key},
        ExpiresIn=SIGNED_URL_TIMEOUT)
    
    ffmpeg_cmd = "/opt/bin/ffmpeg -i \"" + s3_source_signed_url + "\" -c:a pcm_f32le " + s3_destination_filename + " -"
    
    
    command1 = shlex.split(ffmpeg_cmd)
    p1 = subprocess.run(command1, stdout=subprocess.PIPE, stderr=subprocess.PIPE)

    resp = s3_client.put_object(Body=p1.stdout, Bucket=S3_DESTINATION_BUCKET, Key=s3_destination_filename)

    return {
        'statusCode': 200,
        'body': json.dumps('Processing complete successfully')
    }
 


  


• Anomalie #3504 : anomalie dans cvt_autosave : les purges ne se font pas

  23 juillet 2015, par Peet du

  Tu as raison...une fois que tu valides ton formulaire (avec _autosave activé), les données de session concernant CE formulaire sont bien purgées. Pas de bug en l’état puisque ce traitement n’est pas basé sur la constante _AUTOSAVE_GB_DELAY

  Ce que j’avais oublié de préciser dans mon post, c’est que le bug signalé se situe dans la deuxième partie du traitement, celle qui "purge aussi toutes les vieilles autosave". C’est elle qui est basée sur _AUTOSAVE_GB_DELAY.
  Voir https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/cvt_autosave.php#L88

  Si j’ai bien compris, elle traite le cas où le site contient plusieurs formulaires CVT avec l’autosave activé. Dans ce cas on purge également ces sessions.
  Et c’est là que le bug sur le timestamp fait son office. Ces vieilles sessions ne seront jamais purgés.

  SUGGESTION
  Perso, je trouve que ce fonctionnement est astucieux, mais il induit un fonctionnement confus pour l’utilisateur et pour le développeur.
  Si le visiteur revient sur son formulaire, (même 1 an après) il trouve les champs remplis puisque _AUTOSAVE_GB_DELAY n’est pas pris en compte dans ce cas . Il valide son formulaire et sa session pour ce formulaire est purgé.
  Puis dans la foulée il arrive sur un autre formulaire et là....rien ?! (ben oui, il a validé le premier et la purge basée sur _AUTOSAVE_GB_DELAY a fonctionnée (si on corrige le bug hein ;-)

  Bref, perso j’ai modifié le core (je sais, c’est mal) en mettant les purges uniquement basée sur _AUTOSAVE_GB_DELAY dans la fonction cvtautosave_formulaire_charger. On (peut) garder la purge à la validation du formulaire.

  SUGGESTION 2
  L’idéal serait, selon moi, de garder cette dernière idée avec un ajout : on purge dans le répertoire /sessions toutes les données de tous les utilisateurs pour lesquels la valeurs _AUTOSAVE_GB_DELAY a été dépassé. Ça marche bien et de plus, d’un point de vue de sécurité, cela règle en partie le problème des personnes qui on mal lu la doc sur la partie "Vie privée" (voir http://www.spip.net/fr_article5428.html).

  SUGGESTION 3
  même si vous n’êtes pas d’accord avec mon analyse, serait-il possible de mettre

  • cvtautosave_formulaire_charger
  • cvtautosave_formulaire_traiter

  en _dist ?