Recherche avancée
Autres articles (54)
-
Le plugin : Podcasts.
14 juillet 2010, parLe problème du podcasting est à nouveau un problème révélateur de la normalisation des transports de données sur Internet.
Deux formats intéressants existent : Celui développé par Apple, très axé sur l’utilisation d’iTunes dont la SPEC est ici ; Le format "Media RSS Module" qui est plus "libre" notamment soutenu par Yahoo et le logiciel Miro ;
Types de fichiers supportés dans les flux
Le format d’Apple n’autorise que les formats suivants dans ses flux : .mp3 audio/mpeg .m4a audio/x-m4a .mp4 (...) -
Gestion générale des documents
13 mai 2011, parMédiaSPIP ne modifie jamais le document original mis en ligne.
Pour chaque document mis en ligne il effectue deux opérations successives : la création d’une version supplémentaire qui peut être facilement consultée en ligne tout en laissant l’original téléchargeable dans le cas où le document original ne peut être lu dans un navigateur Internet ; la récupération des métadonnées du document original pour illustrer textuellement le fichier ;
Les tableaux ci-dessous expliquent ce que peut faire MédiaSPIP (...) -
Taille des images et des logos définissables
9 février 2011, parDans beaucoup d’endroits du site, logos et images sont redimensionnées pour correspondre aux emplacements définis par les thèmes. L’ensemble des ces tailles pouvant changer d’un thème à un autre peuvent être définies directement dans le thème et éviter ainsi à l’utilisateur de devoir les configurer manuellement après avoir changé l’apparence de son site.
Ces tailles d’images sont également disponibles dans la configuration spécifique de MediaSPIP Core. La taille maximale du logo du site en pixels, on permet (...)
Sur d’autres sites (3287)
-
avformat/mov : fix seeking with HEVC open GOP files
18 février 2022, par Clément Bœschavformat/mov : fix seeking with HEVC open GOP files
This was tested with medias recorded from an iPhone XR and an iPhone 13.
Here is how a typical stream looks like in coding order :
┌────────┬─────┬─────┬──────────┐
│ sample | PTS | DTS | keyframe |
├────────┼─────┼─────┼──────────┤
┊ ┊ ┊ ┊ ┊
│ 53 │ 560 │ 510 │ No │
│ 54 │ 540 │ 520 │ No │
│ 55 │ 530 │ 530 │ No │
│ 56 │ 550 │ 540 │ No │
│ 57 │ 600 │ 550 │ Yes │
│ * 58 │ 580 │ 560 │ No │
│ * 59 │ 570 │ 570 │ No │
│ * 60 │ 590 │ 580 │ No │
│ 61 │ 640 │ 590 │ No │
│ 62 │ 620 │ 600 │ No │
┊ ┊ ┊ ┊ ┊In composition/display order :
┌────────┬─────┬─────┬──────────┐
│ sample | PTS | DTS | keyframe |
├────────┼─────┼─────┼──────────┤
┊ ┊ ┊ ┊ ┊
│ 55 │ 530 │ 530 │ No │
│ 54 │ 540 │ 520 │ No │
│ 56 │ 550 │ 540 │ No │
│ 53 │ 560 │ 510 │ No │
│ * 59 │ 570 │ 570 │ No │
│ * 58 │ 580 │ 560 │ No │
│ * 60 │ 590 │ 580 │ No │
│ 57 │ 600 │ 550 │ Yes │
│ 63 │ 610 │ 610 │ No │
│ 62 │ 620 │ 600 │ No │
┊ ┊ ┊ ┊ ┊Sample/frame 58, 59 and 60 are B-frames which actually depends on the
key frame (57). Here the key frame is not an IDR but a "CRA" (Clean
Random Access).Initially, I thought I could rely on the sdtp box (independent and
disposable samples), but unfortunately :sdtp[54] is_leading:0 sample_depends_on:1 sample_is_depended_on:0 sample_has_redundancy:0
sdtp[55] is_leading:0 sample_depends_on:1 sample_is_depended_on:2 sample_has_redundancy:0
sdtp[56] is_leading:0 sample_depends_on:1 sample_is_depended_on:2 sample_has_redundancy:0
sdtp[57] is_leading:0 sample_depends_on:2 sample_is_depended_on:0 sample_has_redundancy:0
sdtp[58] is_leading:0 sample_depends_on:1 sample_is_depended_on:0 sample_has_redundancy:0
sdtp[59] is_leading:0 sample_depends_on:1 sample_is_depended_on:2 sample_has_redundancy:0
sdtp[60] is_leading:0 sample_depends_on:1 sample_is_depended_on:2 sample_has_redundancy:0
sdtp[61] is_leading:0 sample_depends_on:1 sample_is_depended_on:0 sample_has_redundancy:0
sdtp[62] is_leading:0 sample_depends_on:1 sample_is_depended_on:0 sample_has_redundancy:0The information that might have been useful here would have been
is_leading, but all the samples are set to 0 so this was unusable.Instead, we need to rely on sgpd/sbgp tables. In my case the video track
contained 3 sgpd tables with the following grouping types : tscl, sync
and tsas. In the sync table we have the following 2 entries (only) :sgpd.sync[1] : sync nal_unit_type:0x14
sgpd.sync[2] : sync nal_unit_type:0x15(The count starts at 1 because 0 carries the undefined semantic, we'll
see that later in the reference table).The NAL unit types presented here correspond to :
libavcodec/hevc.h : HEVC_NAL_IDR_N_LP = 20,
libavcodec/hevc.h : HEVC_NAL_CRA_NUT = 21,In parallel, the sbgp sync table contains the following :
┌────┬───────┬─────┐
│ id │ count │ gdi │
├────┼───────┼─────┤
│ 0 │ 1 │ 1 │
│ 1 │ 56 │ 0 │
│ 2 │ 1 │ 2 │
│ 3 │ 59 │ 0 │
│ 4 │ 1 │ 2 │
│ 5 │ 59 │ 0 │
│ 6 │ 1 │ 2 │
│ 7 │ 59 │ 0 │
│ 8 │ 1 │ 2 │
│ 9 │ 59 │ 0 │
│ 10 │ 1 │ 2 │
│ 11 │ 11 │ 0 │
└────┴───────┴─────┘The gdi column (group description index) directly refers to the index in
the sgpd.sync table. This means the first frame is an IDR, then we have
batches of undefined frames interlaced with CRA frames. No IDR ever
appears again (tried on a 30+ seconds sample).With that information, we can build an heuristic using the presentation
order.A few things needed to be introduced in this commit :
1. min_sample_duration is extracted from the stts : we need the minimal
step between sample in order to PTS-step backward to a valid point
2. In order to avoid a loop over the ctts table systematically during a
seek, we build an expanded list of sample offsets which will be used
to translate from DTS to PTS
3. An open_key_samples index to keep track of all the non-IDR key
frames ; for now it only supports HEVC CRA frames. We should probably
add BLA frames as well, but I don't have any sample so I prefered to
leave that for laterIt is entirely possible I missed something obvious in my approach, but I
couldn't come up with a better solution. Also, as mentioned in the diff,
we could optimize is_open_key_sample(), but the linear scaling overhead
should be fine for now since it only happens in seek events.Fixing this issue prevents sending broken packets to the decoder. With
FFmpeg hevc decoder the frames are skipped, with VideoToolbox the frames
are glitching. -
fileapi::WriteFile() doesn't send an input, if processthreadsapi::STARTUPINFO::hStdError is set (ffmpeg)
23 avril 2021, par LidekysI'm trying to capture my screen using
ffmpegin a different thread (which I create usingprocessthreadsapi::CreateProcess())so I'd be able to do something else in the main thread, and redirectffmpegoutput, so it wouldn't pop up in the console for the user to see. To stop filming, I send a 'q' input usingWriteFile(), and after that I want to saveffmpegaccumulated output usingReadFile().

However, if I set
STARTUPINFO::hStdError(note, thatffmpegoutput goes tostderr) to a pipe, from which I could read the accumulated data, the inputs I send usingWriteFile()are no longer registered and ffmpeg.exe keeps running.

I've tried redirecting
ffmpegoutput in a simple command line, but I can still stop the process by pressing the q button.

Also, if I record for less than 8 seconds, the input is registered and
ffmpeg.execloses.

Is there something wrong with my code, or is it processthreadsapi issue, any hints will be kindly appreciared !


Here's a minimal code of how I am trying to do it :



#include <iostream>

#include 
#include 

using namespace std;

HANDLE g_hChildStd_IN_Rd = NULL;
HANDLE g_hChildStd_IN_Wr = NULL;
HANDLE g_hChildStd_OUT_Rd = NULL;
HANDLE g_hChildStd_OUT_Wr = NULL;

int main()
{
 //Create IN and OUT pipes
 SECURITY_ATTRIBUTES saAttr;
 saAttr.nLength = sizeof(SECURITY_ATTRIBUTES);
 saAttr.lpSecurityDescriptor = NULL;


 if (! CreatePipe(&g_hChildStd_OUT_Rd, &g_hChildStd_OUT_Wr, &saAttr, 0) )
 cout<<"StdoutRd CreatePipe error"</Start recording
 if(!CreateProcess(NULL,
 "ffmpeg -y -f gdigrab -framerate 2 -i desktop record.avi", // command line
 NULL, // process security attributes
 NULL, // primary thread security attributes
 TRUE, // handles are inherited
 0, // creation flags
 NULL, // use parent's environment
 NULL, // use parent's current directory
 &siStartInfo, // STARTUPINFO pointer
 &piProcInfo)) // receives PROCESS_INFORMATION
 {
 cout<<"Error create process"</Record for a while
 while(getch() != 'k'){
 cout<<"While press k"</Stop recording by emulating a Q button push
 DWORD dwWritten;
 CHAR chBufW[1] = {'q'};

 if ( ! WriteFile(g_hChildStd_IN_Wr, chBufW, 1, &dwWritten, NULL) )
 cout<<"Error write file"</Save stdError (ffmpeg) data
 DWORD dwRead;
 char stdErrorData[4096];
 bool bSuccess;

 bSuccess = ReadFile( g_hChildStd_OUT_Wr, stdErrorData, 4096, &dwRead, NULL);

 if(!bSuccess || dwRead == 0)
 cout<<"Read failed"<code></iostream>

-
Puzzled with file descriptor in Bash (ffmpeg video capture)
3 mai 2020, par ChrisAgaI am trying to use file descriptors in Bash and found a problem I cannot solve.
I have to read a video stream coming from the standard output of a command executed in a
coproc. This piece of code works as expected :


ffmpeg \
 -i <(exec cat <&${COPROC[0]}) \
 -c:v $ENCODE_VIDEO_FORMAT_LOSSLESS $ENCODE_VIDEO_OPTIONS_LOSSLESS \
 -c:a copy \
 -progress /dev/fd/1 \
 "${capfile}"



But the
catprocess is not really useful sinceffmpeg -i pipe:<file descriptor="descriptor"></file>seems to do the same. So I tried the following code which fails withpipe:63: Bad file descriptor
error.


ffmpeg \
 -i pipe:"${COPROC[0]}" \
 -c:v $ENCODE_VIDEO_FORMAT_LOSSLESS $ENCODE_VIDEO_OPTIONS_LOSSLESS \
 -c:a copy \
 -progress /dev/fd/1 \
 "${capfile}"



The actual script is something a bit complicated but here is a minimal testing code for this issue :



#!/bin/bash
#

ENCODE_VIDEO_FORMAT_LOSSLESS=ffv1
ENCODE_VIDEO_OPTIONS_LOSSLESS="-level 3 -threads 7 -coder 1 -context 1 -g 1 -slices 30 -slicecrc 1"

capfile=capure.mkv

coproc ffmpeg -i file:'Camomille.mkv' -c:v copy -c:a copy -f matroska pipe:1

capture_fd=${COPROC[0]}
echo "hk_capture_pid=${COPROC_PID}"

ffmpeg \
 -i pipe:${COPROC[0]} \
 -c:v $ENCODE_VIDEO_FORMAT_LOSSLESS $ENCODE_VIDEO_OPTIONS_LOSSLESS \
 -c:a copy \
 -progress /dev/fd/1 \
 "${capfile}"



This is the output of the second
ffmpegcommand :


ffmpeg version 4.1.4-1build2 Copyright (c) 2000-2019 the FFmpeg developers
 built with gcc 9 (Ubuntu 9.2.1-4ubuntu1)
 configuration: --prefix=/usr --extra-version=1build2 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared
 libavutil 56. 22.100 / 56. 22.100
 libavcodec 58. 35.100 / 58. 35.100
 libavformat 58. 20.100 / 58. 20.100
 libavdevice 58. 5.100 / 58. 5.100
 libavfilter 7. 40.101 / 7. 40.101
 libavresample 4. 0. 0 / 4. 0. 0
 libswscale 5. 3.100 / 5. 3.100
 libswresample 3. 3.100 / 3. 3.100
 libpostproc 55. 3.100 / 55. 3.100
pipe:63: Bad file descriptor
av_interleaved_write_frame(): Broken pipe 
Error writing trailer of pipe:1: Broken pipe 
frame= 4 fps=0.0 q=-1.0 Lsize= 48kB time=00:00:00.03 bitrate=10051.1kbits/s speed=3.44x 
video:86kB audio:1kB subtitle:0kB other streams:0kB global headers:2kB muxing overhead: unknown
Conversion failed!



This one fails and if you replace
-i pipe:${COPROC[0]}by-i <(exec cat <&${COPROC[0]})a capture.mkv file is created.


I run ubuntu eoan and bash version is :
GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu). I upgraded several times since I started with this issue, so it wouldn't be related too much to bash and ffmpeg versions.


If someone can point me to what I do wrong with bash file descriptors I would be grateful.


Syndiquer tout le site
