
Recherche avancée
Médias (1)
-
SPIP - plugins - embed code - Exemple
2 septembre 2013, par
Mis à jour : Septembre 2013
Langue : français
Type : Image
Autres articles (72)
-
Personnaliser en ajoutant son logo, sa bannière ou son image de fond
5 septembre 2013, parCertains thèmes prennent en compte trois éléments de personnalisation : l’ajout d’un logo ; l’ajout d’une bannière l’ajout d’une image de fond ;
-
Ecrire une actualité
21 juin 2013, parPrésentez les changements dans votre MédiaSPIP ou les actualités de vos projets sur votre MédiaSPIP grâce à la rubrique actualités.
Dans le thème par défaut spipeo de MédiaSPIP, les actualités sont affichées en bas de la page principale sous les éditoriaux.
Vous pouvez personnaliser le formulaire de création d’une actualité.
Formulaire de création d’une actualité Dans le cas d’un document de type actualité, les champs proposés par défaut sont : Date de publication ( personnaliser la date de publication ) (...) -
Publier sur MédiaSpip
13 juin 2013Puis-je poster des contenus à partir d’une tablette Ipad ?
Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir
Sur d’autres sites (13090)
-
avformat/dvdvideodec : fix seeking on multi-angle discs
1er février, par Marth64avformat/dvdvideodec : fix seeking on multi-angle discs
When seeking on multi-angle titles, libdvdnav does not lock on
to the correct sectors initially as it seeks to find the right NAV packet.This manifests itself as two bugs :
(1) When seeking on the first angle in a multi-angle segment,
frames from another angle will appear (for example in intro
or credits scenes). This issue is present in VLC also.(2) When seeking during a segment on angle n+1, the demuxer
cannot deduce the right position from dvdnav and does not allow
seeking within the segment (due to it maintaining a strict state).Correct the issue by switching to angle 1 before doing the seek
operation, and skipping 3 VOBUs (NAV packet led segments) ahead
where dvdnav will have positioned itself correctly.Reported-by : Kacper Michajlow <kasper93@gmail.com>
Signed-off-by : Marth64 <marth64@proxyid.net> -
FFmpeg WASM Compilation with Hardware-Accelerated H.264/HEVC Decoding
20 juillet, par gt-develI'm working on a media processing SDK with a substantial C++ codebase that currently uses FFmpeg for video decoding on native platforms (Windows/Linux). I need to port this to browsers while preserving both the existing C++ architecture and performance characteristics. The WASM approach is critical for us because it allows leveraging our existing optimized C++ media processing pipeline without a complete JavaScript rewrite, while maintaining the performance benefits of compiled native code.


The Challenge :
WebAssembly runs in a browser sandbox that typically doesn't allow direct GPU access, which conflicts with our hardware-accelerated video decoding requirements. Pure JavaScript solutions would require abandoning our mature C++ codebase and likely result in significant performance degradation.


My Questions :


- 

-
Is it technically feasible to compile FFmpeg with hardware acceleration support (NVENC/VAAPI/VideoToolbox) for WASM targets ? Additionally, can the underlying hardware acceleration dependencies (like CUDA runtime, Intel Media SDK, or platform-specific GPU drivers) be compiled as WASM modules, and would this approach serve the purpose of enabling hardware acceleration in the browser environment ?


-
Are there any emerging browser APIs or proposals (like WebGPU, WebCodecs API) that could provide a pathway for hardware-accelerated video decoding in WASM modules while preserving our C++ architecture ?


-
Has anyone successfully implemented hardware-accelerated video decoding in a browser environment using WASM, or are there alternative approaches that would allow us to maintain our existing C++ codebase and performance requirements ?










Context :


- 

- Extensive C++ media processing pipeline with FFmpeg 7.1.0
- Target streams : H.264 and HEVC
- Performance requirements make software-only decoding insufficient
- Rewriting the entire codebase in JavaScript is not feasible due to complexity and performance constraints










Any insights, experiences, or alternative architectural suggestions that preserve our C++ investment would be greatly appreciated !


I attempted to compile FFmpeg for WebAssembly using Emscripten with hardware acceleration enabled. My approach was to call the FFmpeg configure script from a Linux bash environment using :


emconfigure ./configure \
 --target-os=none \
 --arch=x86_32 \
 --enable-cross-compile \
 --disable-debug \
 --disable-x86asm \
 --disable-inline-asm \
 --disable-stripping \
 --disable-programs \
 --disable-doc \
 --disable-all \
 --enable-avcodec \
 --enable-gray \
 --enable-avformat \
 --enable-avfilter \
 --enable-avdevice \
 --enable-avutil \
 --enable-swresample \
 --enable-swscale \
 --enable-filters \
 --enable-protocol=file \
 --enable-decoder=h264 \
 --enable-vaapi \
 --enable-hwaccel=h264_vaapi \
 --enable-gpl \
 --enable-pthreads \
 --extra-cflags="-O3 -I$ffmpegIncludesDir -I$libvaIncludesDir" \
 --extra-cxxflags="-O3 -I$ffmpegIncludesDir -I$libvaIncludesDir" \
 --extra-ldflags="--initial-memory=33554432 --no-entry --relocatable -L$ffmpegLibrariesDir -L$libvaLibrariesDir" \
 --nm="emnm -g" \
 --ar=emar \
 --as="$EMSDK/upstream/bin/wasm-as" \
 --ranlib=emranlib \
 --cc=emcc \
 --cxx=em++ \
 --objcc=emcc \
 --dep-cc=emcc



Since I specified
x86_32
architecture, I provided the i386 version of the libva (VAAPI) library to match the target architecture. However, the configuration failed with the error"unknown file type: /usr/lib/i386-linux-gnu/libva.so"
in the resultingconfig.log
file.

This error suggests that Emscripten's toolchain cannot process native Linux shared libraries (.so files), which makes sense since these are compiled for native execution rather than WebAssembly. The configuration specifically targets VAAPI hardware acceleration for H.264 decoding, but this approach appears fundamentally flawed since VAAPI requires direct hardware access that isn't available in the browser sandbox, and the native libraries cannot be linked into a WASM module.


This experience has led me to question whether the hardware acceleration dependencies can be meaningfully compiled for WASM, or if alternative approaches are needed.


-
-
exe file not executing from deployed ASP.NET MVC app in TAS (Tanzu /PCF)
24 juin, par Darshan AdakaneI am facing an issue for my ASP.NET MVC web application on .NET 4 being deployed to TAS.


I am trying to do image compression using
ffmpeg.exe
.

While it is working on my local machine, I get an "500 internal server error" when deployed to TAS (tanzu application server). I am using
hwc_buildpack
and storing the file inPath.GetTemp()
folder for testing.

applications:
- name: MyApp-Dev
 memory: 1G
 instances: 1
 stack: windows
 buildpacks:
 - hwc_buildpack
 path: \MyAppnew\obj\Release\Package\PackageTmp
 env:
 services:
 routes:
 - route: myapp-dev.apps.company.com
 - route: myapp-dev.company.com



I also see that the
.exe
is being published when app I deployed. I am assuming if TAS has NO permission to read exe or read exe 'not allowed' policy.

This is my code :


[HttpPost]
[Route("uploadimage")]
public async Task<ihttpactionresult> UploadImage()
{
 try
 {
 if (!Request.Content.IsMimeMultipartContent())
 return BadRequest("Unsupported media type.");

 Console.WriteLine("UploadImage method started.");

 var provider = new MultipartMemoryStreamProvider();
 await Request.Content.ReadAsMultipartAsync(provider);

 Console.WriteLine($"Total Files available: {provider.Contents.Count}, {provider.Contents}");

 foreach (var file in provider.Contents)
 {
 try
 {
 var imageFile = await file.ReadAsByteArrayAsync();
 Console.WriteLine($"imageFile, { imageFile.Length }");
 var rawFileName = file.Headers.ContentDisposition.FileName.Trim('"');
 Console.WriteLine($"rawFileName, {rawFileName}");
 var fileName = Path.GetFileName(rawFileName); // Sanitize filename
 Console.WriteLine($"fileName, {fileName}");

 // Check file size limit (300MB)
 if (imageFile.Length > 300 * 1024 * 1024) // 300MB limit
 {
 Console.WriteLine("File size exceeds 300MB limit.");
 return BadRequest("File size exceeds 300MB limit.");
 }

 var inputFilePath = Path.Combine(_uploadFolder, fileName);
 Console.WriteLine($"inputFilePath, {inputFilePath}");

 var outputFilePath = Path.Combine(_uploadFolder, "compressed_" + fileName);
 Console.WriteLine($"outputFilePath, {outputFilePath}");

 // Save uploaded file to disk
 File.WriteAllBytes(inputFilePath, imageFile);

 // Check if the input file exists
 if (!File.Exists(inputFilePath))
 {
 Console.WriteLine($"Input file does not exist: {inputFilePath}");
 return InternalServerError(new Exception($"❌ Input file does not exist: {inputFilePath}"));
 }

 //Console.WriteLine($"✅ FFmpeg found at path: {ffmpegFullPath}");

 await FFMpegArguments
 .FromFileInput(inputFilePath)
 .OutputToFile(outputFilePath, overwrite: true, options => options
 .WithCustomArgument("-vf scale=800:-1")
 .WithCustomArgument("-q:v 10")
 )
 .ProcessAsynchronously();

 Console.WriteLine($"outputFilePath, {outputFilePath}");

 // Check if the output file was created
 if (File.Exists(outputFilePath))
 {
 var fileInfo = new FileInfo(outputFilePath); // Get file info

 Console.WriteLine($"outputFileInfoPropsFullName, {fileInfo.FullName}");
 Console.WriteLine($"outputFileInfoPropsLength, {fileInfo.Length}");

 var compressedFileBytes = File.ReadAllBytes(outputFilePath);
 var compressedFileBase64 = Convert.ToBase64String(compressedFileBytes);

 return Ok(new
 {
 Message = "Image uploaded and compressed successfully.",
 CompressedImagePath = outputFilePath,
 CompressedFileSize = fileInfo.Length, // Size in bytes
 CompressedFileBase64 = compressedFileBase64
 });
 }
 else
 {
 Console.WriteLine("OutputFilePath File not exists.");
 return InternalServerError(new Exception($"❌ Failed to create compressed file: {outputFilePath}"));
 });
 }
 catch (Exception ex)
 {
 Console.WriteLine($"File TRYCATCH:{ex}");
 return InternalServerError(new Exception("Image compression failed: " + ex.Message));
 }
 }
 }
 catch (Exception ex)
 {
 Console.WriteLine($"Method TRYCATCH:{ex}");
 throw;
 }

 return BadRequest("No image file uploaded.");
}
</ihttpactionresult>


I'm getting this error in my tanzu environment logs from the code when I execute :


await FFMpegArguments



This is the exception log :


FFMpegCore.Exceptions.FFMpegException: ffmpeg was not found on your system



I also see that the
.exe
files do exist in TAS in these logs :

2025-06-13T16:07:55.878+05:30 [APP/PROC/WEB/0] [OUT] PATH of FFmpeg Executable: C:\Users\vcap\app\ffmpeg-bin\ffmpeg.exe
2025-06-13T16:07:55.878+05:30 [APP/PROC/WEB/0] [OUT] PATH of ffmpegPath: C:\Users\vcap\app\ffmpeg-bin
2025-06-13T16:07:55.878+05:30 [APP/PROC/WEB/0] [OUT] PATH of BaseDirectory: C:\Users\vcap\app\
2025-06-13T16:07:55.881+05:30 [APP/PROC/WEB/0] [OUT] TempPath: C:\Users\vcap\AppData\Local\Temp\ 
 2025-06-24T18:39:50.684+05:30 [APP/PROC/WEB/0] [OUT] at MCANew.Controllers.Api.MessagesController.<uploadimage>d__6.MoveNext() in I:\Agents\Agent-Win-B\_work\3033\s\MCANew\Controllers\Api\MessagesController.cs:line 133
2025-06-24T18:39:50.684+05:30 [APP/PROC/WEB/0] [OUT] at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
2025-06-24T18:39:50.684+05:30 [APP/PROC/WEB/0] [OUT] --- End of stack trace from previous location where exception was thrown ---
2025-06-24T18:39:50.684+05:30 [APP/PROC/WEB/0] [OUT] at FFMpegCore.FFMpegArgumentProcessor.<processasynchronously>d__24.MoveNext()
2025-06-24T18:39:50.684+05:30 [APP/PROC/WEB/0] [OUT] at FFMpegCore.FFMpegArgumentProcessor.PrepareProcessArguments(FFOptions ffOptions, CancellationTokenSource& cancellationTokenSource)
2025-06-24T18:39:50.684+05:30 [APP/PROC/WEB/0] [OUT] at FFMpegCore.Helpers.FFMpegHelper.VerifyFFMpegExists(FFOptions ffMpegOptions)
2025-06-24T18:39:50.684+05:30 [APP/PROC/WEB/0] [OUT] File TRYCATCH:FFMpegCore.Exceptions.FFMpegException: ffmpeg was not found on your system
</processasynchronously></uploadimage>


My objective is to run successfully exe on TAS and image compression to happen.