Recherche avancée

Sur d’autres sites (9944)

• How to convert a Stream on the fly with FFMpegCore ?

  18 octobre 2023, par Adrian

  For a school project, I need to stream videos that I get from torrents while they are downloading on the server.
When the video is a .mp4 file, there's no problem, but I must also be able to stream .mkv files, and for that I need to convert them into .mp4 before sending them to the client, and I can't find a way to convert my Stream that I get from MonoTorrents with FFMpegCore into a Stream that I can send to my client.

  


  Here is the code I wrote to simply download and stream my torrent :

  


  var cEngine = new ClientEngine();

var manager = await cEngine.AddStreamingAsync(GenerateMagnet(torrent), ) ?? throw new Exception("An error occurred while creating the torrent manager");

await manager.StartAsync();
await manager.WaitForMetadataAsync();

var videoFile = manager.Files.OrderByDescending(f => f.Length).FirstOrDefault();
if (videoFile == null)
    return Results.NotFound();

var stream = await manager.StreamProvider!.CreateStreamAsync(videoFile, true);
return Results.File(stream, contentType: "video/mp4", fileDownloadName: manager.Name, enableRangeProcessing: true);


  


  I saw that the most common way to convert videos is by using ffmpeg. .NET has a package called FFMpefCore that is a wrapper for ffmpeg.

  


  To my previous code, I would add right before the return :

  


  if (!videoFile.Path.EndsWith(".mp4"))
{
    var outputStream = new MemoryStream();
    FFMpegArguments
        .FromPipeInput(new StreamPipeSource(stream), options =>
        {
            options.ForceFormat("mp4");
        })
        .OutputToPipe(new StreamPipeSink(outputStream))
        .ProcessAsynchronously();
    return Results.File(outputStream, contentType: "video/mp4", fileDownloadName: manager.Name, enableRangeProcessing: true);
}


  


  I unfortunately can't get a "live" Stream to send to my client.

  


• avformat/matroskadec : Check min_luminance more thoroughly

  16 février 2021, par Andreas Rheinhardt

  avformat/matroskadec : Check min_luminance more thoroughly
  In the absence of an explicitly coded minimal luminance, the current
  
  code inferred it to be -1, an invalid value. Yet it did not check the
  
  value lateron at all, so that if a valid maximum luminance is
  
  encountered, but no minimal luminance, an invalid minimal luminance of
  
   1 is exported. If an minimal luminance element with a negative value is
  
  present, it is exported, too. This can be simply fixed by adding a check
  
  for the value of the element.
  Yet given that a minimal luminance of zero Cd/m² is legal and can be
  
  coded with a length of zero, we must not use a fake default value to
  
  find out whether the element is present or not. Therefore this patch
  
  uses an explicit counter for it.
  While just at it, also check for max_luminance > min_luminance.
  Reviewed-by : Ridley Combs <rcombs@rcombs.me>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/matroskadec.c

• Anomalie #3055 (En cours) : Autorisation sur les listes d’objets

  5 mai 2015, par Eric Lupinacci

  En fait, c’est à mon avis un problème plus général, de rigueur dans l’appel des autorisations en entrée des pages mais aussi de stratégie de définition des autorisations qui sont malheureusement assez rarement arborescentes.

  Si on prend les pages objet comme article, rubrique et auteur par exemple, elle commencent toutes par une autorisation :
  

  (#AUTORISERvoir,article,#ID_ARTICLE ou
  (#AUTORISERvoir,rubrique,#ID_RUBRIQUE ou
  (#AUTORISERvoir,auteur,#ID_AUTEUR
  

  
  Cependant d’ailleurs seul l’autorisation article_voir est définie, les autres renvoyant sur l’autorisation par défaut. Mais au moins une autorisation est appelée systématiquement quelque soit le moyen avec lequel on arrive sur cette page.
  A partir de là si il existe un bouton qui envoie sur cette page il faut le conditionner par cette autorisation (code HTML) et si c’est un menu créé automatiquement alors là il faut créer une autorisation de menu qui appelle l’autorisation de voir et pas le contraire à mon avis.

  Donc si on étend ça aux pages articles, auteurs et rubriques je suis d’accord qu’il faudrait une autorisation voir_xxxx (ce qui n’est pas le cas actuellement) qui serait appelée en entrée de la page comme l’exemple ci-dessous pour la page articles :
  

  (#AUTORISERvoir,_articles
  

  
  et il faudrait alors coder l’autorisation du menu Articles de cette façon :
  

  function autoriser_articles_menu_dist($faire, $type, $id, $qui, $opt) 
      return autoriser(’voir’, ’_articles’) ;
  
  

  
  En effet, la décision d’afficher ou pas le menu est indépendante du fait de voir ou pas la page articles mais doit s’appuyer dessus si on décide de ne pas présenter un lien qui mène vers une page interdite.
  Et il faudrait systématiser cela pour tous les plugins objet du core à mon avis.

  En second lieu il faudrait faire une passe sur le code des autorisations actuelles pour imbriquer un peu plus les autorisations de façon arborescente ce qui leur donnerait plus de lisibilité car parfois elles sont identiques sans qu’on s’en rende compte car le code est dupliqué.