
Recherche avancée
Autres articles (65)
-
Participer à sa traduction
10 avril 2011Vous pouvez nous aider à améliorer les locutions utilisées dans le logiciel ou à traduire celui-ci dans n’importe qu’elle nouvelle langue permettant sa diffusion à de nouvelles communautés linguistiques.
Pour ce faire, on utilise l’interface de traduction de SPIP où l’ensemble des modules de langue de MediaSPIP sont à disposition. ll vous suffit de vous inscrire sur la liste de discussion des traducteurs pour demander plus d’informations.
Actuellement MediaSPIP n’est disponible qu’en français et (...) -
Les autorisations surchargées par les plugins
27 avril 2010, parMediaspip core
autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs -
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 (9363)
-
Ffmpeg only receives a piece of information from the pipe
4 juillet 2017, par Maxim FedorovFirst of all - my english is not very good, i`m sorry for that.
I use ffmpeg from c# to convert images to video. To interact with ffmpeg, I use pipes.
public async Task ExecuteCommand(
string arguments,
Action<namedpipeserverstream> sendDataUsingPipe)
{
var inStream = new NamedPipeServerStream(
"from_ffmpeg",
PipeDirection.In,
1,
PipeTransmissionMode.Byte,
PipeOptions.Asynchronous,
PipeBufferSize,
PipeBufferSize);
var outStream = new NamedPipeServerStream(
"to_ffmpeg",
PipeDirection.Out,
1,
PipeTransmissionMode.Byte,
PipeOptions.Asynchronous,
PipeBufferSize,
PipeBufferSize);
var waitInConnectionTask = inStream.WaitForConnectionAsync();
var waitOutConnectionTask = outStream.WaitForConnectionAsync();
byte[] byteData;
using (inStream)
using (outStream)
using (var inStreamReader = new StreamReader(inStream))
using (var process = new Process())
{
process.StartInfo = new ProcessStartInfo
{
RedirectStandardOutput = true,
RedirectStandardError = true,
RedirectStandardInput = true,
FileName = PathToFfmpeg,
Arguments = arguments,
UseShellExecute = false,
CreateNoWindow = true
};
process.Start();
await waitOutConnectionTask;
sendDataUsingPipe.Invoke(outStream);
outStream.Disconnect();
outStream.Close();
await waitInConnectionTask;
var logTask = Task.Run(() => process.StandardError.ReadToEnd());
var dataBuf = ReadAll(inStream);
var shouldBeEmpty = inStreamReader.ReadToEnd();
if (!string.IsNullOrEmpty(shouldBeEmpty))
throw new Exception();
var processExitTask = Task.Run(() => process.WaitForExit());
await Task.WhenAny(logTask, processExitTask);
var log = logTask.Result;
byteData = dataBuf;
process.Close();
inStream.Disconnect();
inStream.Close();
}
return byteData;
}
</namedpipeserverstream>Action "sendDataUsingPipe" looks like
Action<namedpipeserverstream> sendDataUsingPipe = stream =>
{
foreach (var imageBytes in data)
{
using (var image = Image.FromStream(new MemoryStream(imageBytes)))
{
image.Save(stream, ImageFormat.Jpeg);
}
}
};
</namedpipeserverstream>When I send 10/20/30 images (regardless of the size) ffmpeg processes everything.
When I needed to transfer 600/700 / .. images, then in the ffmpeg log I see that it only received 189-192, and in the video there are also only 189-192 images.
There are no errors in the logs or exceptions in the code.What could be the reason for this behavior ?
-
What could be causing processes to be left behind ?
11 novembre 2015, par AlexI’m using the
Process
class to spawn a process (in particular, I’m usingffmpeg.exe
to convert some video files). Thisffmpeg
process spawns more processes (on my computer, the total is 4, I’m guessing one per CPU core ?). If it matters, I’m doing this in a Windows service, although the problem also occurs when just debugging in Visual Studio, so I don’t think it does matter.The main
ffmpeg
process runs as expected and exits, causing theWaitForExit()
call to return. Except, unlike when run normally (i.e. in a command prompt), the three processes that were spawned hang around. And they keep hanging around until the process that spawned the originalffmpeg.exe
process (i.e. my service) is ended.Any ideas what this could be about ?
My `ProcessStartInfo looks like this :
_processStartInfo = new ProcessStartInfo(process, string.Join(" ", parameters))
{
UseShellExecute = false,
CreateNoWindow = true,
RedirectStandardOutput = true,
RedirectStandardError = true
};I launch the
Process
like this :_process = Process.Start(_processStartInfo);
_outputReceivedHandler = (sender, e) =>
{
if (OutputData != null) OutputData(e.Data);
};
_process.OutputDataReceived += _outputReceivedHandler;
_errorReceivedHandler = (sender, e) =>
{
if (ErrorData != null) ErrorData(e.Data);
};
_process.ErrorDataReceived += _errorReceivedHandler;
_exitHandler = (sender, e) =>
{
if (Exited != null) Exited();
};
_process.EnableRaisingEvents = true;
_process.Exited += _exitHandler;
_process.Start();
_process.BeginOutputReadLine();
_process.BeginErrorReadLine();If it’s relevant,
OutputData
,ErrorData
andExited
areAction<string></string>
,Action<string></string>
andAction
, respectively.The reason I’m keeping the various handlers around is so that I can do this :
private bool _disposed;
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (_disposed || !disposing) return;
if (_outputReceivedHandler != null) _process.OutputDataReceived -= _outputReceivedHandler;
if (_errorReceivedHandler != null) _process.ErrorDataReceived -= _errorReceivedHandler;
if (_exitHandler != null) _process.Exited -= _exitHandler;
if (_process != null) _process.Dispose();
_disposed = true;
}Though it hasn’t made a difference whether or not I use
Dispose()
, the problem still occurs. -
avcodec/movtextenc : Fix potential use of uninitialized value
15 octobre 2020, par Andreas Rheinhardtavcodec/movtextenc : Fix potential use of uninitialized value
Background colour was never initialized if no style was available.
Use a sane default of zero (i.e. completely transparent).Fixes Coverity issue #1461471.
Reviewed-by : Philip Langdale <philipl@overt.org>
Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>