
Recherche avancée
Médias (91)
-
Spitfire Parade - Crisis
15 mai 2011, par
Mis à jour : Septembre 2011
Langue : English
Type : Audio
-
Wired NextMusic
14 mai 2011, par
Mis à jour : Février 2012
Langue : English
Type : Video
-
Video d’abeille en portrait
14 mai 2011, par
Mis à jour : Février 2012
Langue : français
Type : Video
-
Sintel MP4 Surround 5.1 Full
13 mai 2011, par
Mis à jour : Février 2012
Langue : English
Type : Video
-
Carte de Schillerkiez
13 mai 2011, par
Mis à jour : Septembre 2011
Langue : English
Type : Texte
-
Publier une image simplement
13 avril 2011, par ,
Mis à jour : Février 2012
Langue : français
Type : Video
Autres articles (16)
-
Les formats acceptés
28 janvier 2010, parLes commandes suivantes permettent d’avoir des informations sur les formats et codecs gérés par l’installation local de ffmpeg :
ffmpeg -codecs ffmpeg -formats
Les format videos acceptés en entrée
Cette liste est non exhaustive, elle met en exergue les principaux formats utilisés : h264 : H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 m4v : raw MPEG-4 video format flv : Flash Video (FLV) / Sorenson Spark / Sorenson H.263 Theora wmv :
Les formats vidéos de sortie possibles
Dans un premier temps on (...) -
Ajouter notes et légendes aux images
7 février 2011, parPour pouvoir ajouter notes et légendes aux images, la première étape est d’installer le plugin "Légendes".
Une fois le plugin activé, vous pouvez le configurer dans l’espace de configuration afin de modifier les droits de création / modification et de suppression des notes. Par défaut seuls les administrateurs du site peuvent ajouter des notes aux images.
Modification lors de l’ajout d’un média
Lors de l’ajout d’un média de type "image" un nouveau bouton apparait au dessus de la prévisualisation (...) -
La sauvegarde automatique de canaux SPIP
1er avril 2010, parDans le cadre de la mise en place d’une plateforme ouverte, il est important pour les hébergeurs de pouvoir disposer de sauvegardes assez régulières pour parer à tout problème éventuel.
Pour réaliser cette tâche on se base sur deux plugins SPIP : Saveauto qui permet une sauvegarde régulière de la base de donnée sous la forme d’un dump mysql (utilisable dans phpmyadmin) mes_fichiers_2 qui permet de réaliser une archive au format zip des données importantes du site (les documents, les éléments (...)
Sur d’autres sites (3389)
-
x264 : Expose the NV21 input support
1er août 2015, par Yu Xiaolei -
Ffmpeg program to stitch image side by side
14 mars 2021, par Beyond MotivationSo I have about 90-100 images which are of the resolution 1080x1920px. I want to make a program in ffmpeg that will join them as in stitch them side by side(horizontally), such that all the images combine to become a wide image. Can someone pls help me with a program for this ?


-
How to encode Planar 4:2:0 (fourcc P010)
20 juillet 2021, par DennisFleurbaaijI'm trying to recode fourcc V210 (which is a packed YUV4:2:2 format) into a P010 (planar YUV4:2:0). I think I've implemented it according to spec, but the renderer is giving a wrong image so something is off. Decoding the V210 has a decent example in ffmpeg (defines are modified from their solution) but I can't find a P010 encoder to look at what I'm doing wrong.


(Yes, I've tried ffmpeg and that works but it's too slow for this, it takes 30ms per frame on an Intel Gen11 i7)


Clarification (after @Frank's question) : The frames being processed are 4k (3840px wide) and hence there is no code for doing the 128b alignment.


This is running on intel so little endian conversions applied.


Try1 - all green image :


The following code


#define V210_READ_PACK_BLOCK(a, b, c) \
 do { \
 val = *src++; \
 a = val & 0x3FF; \
 b = (val >> 10) & 0x3FF; \
 c = (val >> 20) & 0x3FF; \
 } while (0)

#define PIXELS_PER_PACK 6
#define BYTES_PER_PACK (4*4)

void MyClass::FormatVideoFrame(
 BYTE* inFrame,
 BYTE* outBuffer)
{
 const uint32_t pixels = m_height * m_width;

 const uint32_t* src = (const uint32_t *)inFrame);

 uint16_t* dstY = (uint16_t *)outBuffer;

 uint16_t* dstUVStart = (uint16_t*)(outBuffer + ((ptrdiff_t)pixels * sizeof(uint16_t)));
 uint16_t* dstUV = dstUVStart;

 const uint32_t packsPerLine = m_width / PIXELS_PER_PACK;

 for (uint32_t line = 0; line < m_height; line++)
 {
 for (uint32_t pack = 0; pack < packsPerLine; pack++)
 {
 uint32_t val;
 uint16_t u, y1, y2, v;

 if (pack % 2 == 0)
 {
 V210_READ_PACK_BLOCK(u, y1, v);
 *dstUV++ = u;
 *dstY++ = y1;
 *dstUV++ = v;

 V210_READ_PACK_BLOCK(y1, u, y2);
 *dstY++ = y1;
 *dstUV++ = u;
 *dstY++ = y2;

 V210_READ_PACK_BLOCK(v, y1, u);
 *dstUV++ = v;
 *dstY++ = y1;
 *dstUV++ = u;

 V210_READ_PACK_BLOCK(y1, v, y2);
 *dstY++ = y1;
 *dstUV++ = v;
 *dstY++ = y2;
 }
 else
 {
 V210_READ_PACK_BLOCK(u, y1, v);
 *dstY++ = y1;

 V210_READ_PACK_BLOCK(y1, u, y2);
 *dstY++ = y1;
 *dstY++ = y2;

 V210_READ_PACK_BLOCK(v, y1, u);
 *dstY++ = y1;

 V210_READ_PACK_BLOCK(y1, v, y2);
 *dstY++ = y1;
 *dstY++ = y2;
 }
 }
 }

#ifdef _DEBUG

 // Fully written Y space
 assert(dstY == dstUVStart);

 // Fully written UV space
 const BYTE* expectedVurrentUVPtr = outBuffer + (ptrdiff_t)GetOutFrameSize();
 assert(expectedVurrentUVPtr == (BYTE *)dstUV);

#endif
}

// This is called to determine outBuffer size
LONG MyClass::GetOutFrameSize() const
{
 const LONG pixels = m_height * m_width;

 return
 (pixels * sizeof(uint16_t)) + // Every pixel 1 y
 (pixels / 2 / 2 * (2 * sizeof(uint16_t))); // Every 2 pixels and every odd row 2 16-bit numbers
}



Leads to all green image. This turned out to be a missing bit shift to place the 10 bits in the upper bits of the 16-bit value as per the P010 spec.


Try 2 - Y works, UV doubled ?


Updated the code to properly (or so I think) shifts the YUV values to the correct position in their 16-bit space.


#define V210_READ_PACK_BLOCK(a, b, c) \
 do { \
 val = *src++; \
 a = val & 0x3FF; \
 b = (val >> 10) & 0x3FF; \
 c = (val >> 20) & 0x3FF; \
 } while (0)


#define P010_WRITE_VALUE(d, v) (*d++ = (v << 6))

#define PIXELS_PER_PACK 6
#define BYTES_PER_PACK (4 * sizeof(uint32_t))

// Snipped constructor here which guarantees that we're processing
// something which does not violate alignment.

void MyClass::FormatVideoFrame(
 const BYTE* inBuffer,
 BYTE* outBuffer)
{ 
 const uint32_t pixels = m_height * m_width;
 const uint32_t aligned_width = ((m_width + 47) / 48) * 48;
 const uint32_t stride = aligned_width * 8 / 3;

 uint16_t* dstY = (uint16_t *)outBuffer;

 uint16_t* dstUVStart = (uint16_t*)(outBuffer + ((ptrdiff_t)pixels * sizeof(uint16_t)));
 uint16_t* dstUV = dstUVStart;

 const uint32_t packsPerLine = m_width / PIXELS_PER_PACK;

 for (uint32_t line = 0; line < m_height; line++)
 {
 // Lines start at 128 byte alignment
 const uint32_t* src = (const uint32_t*)(inBuffer + (ptrdiff_t)(line * stride));

 for (uint32_t pack = 0; pack < packsPerLine; pack++)
 {
 uint32_t val;
 uint16_t u, y1, y2, v;

 if (pack % 2 == 0)
 {
 V210_READ_PACK_BLOCK(u, y1, v);
 P010_WRITE_VALUE(dstUV, u);
 P010_WRITE_VALUE(dstY, y1);
 P010_WRITE_VALUE(dstUV, v);

 V210_READ_PACK_BLOCK(y1, u, y2);
 P010_WRITE_VALUE(dstY, y1);
 P010_WRITE_VALUE(dstUV, u);
 P010_WRITE_VALUE(dstY, y2);

 V210_READ_PACK_BLOCK(v, y1, u);
 P010_WRITE_VALUE(dstUV, v);
 P010_WRITE_VALUE(dstY, y1);
 P010_WRITE_VALUE(dstUV, u);

 V210_READ_PACK_BLOCK(y1, v, y2);
 P010_WRITE_VALUE(dstY, y1);
 P010_WRITE_VALUE(dstUV, v);
 P010_WRITE_VALUE(dstY, y2);
 }
 else
 {
 V210_READ_PACK_BLOCK(u, y1, v);
 P010_WRITE_VALUE(dstY, y1);

 V210_READ_PACK_BLOCK(y1, u, y2);
 P010_WRITE_VALUE(dstY, y1);
 P010_WRITE_VALUE(dstY, y2);

 V210_READ_PACK_BLOCK(v, y1, u);
 P010_WRITE_VALUE(dstY, y1);

 V210_READ_PACK_BLOCK(y1, v, y2);
 P010_WRITE_VALUE(dstY, y1);
 P010_WRITE_VALUE(dstY, y2);
 }
 }
 }

#ifdef _DEBUG

 // Fully written Y space
 assert(dstY == dstUVStart);

 // Fully written UV space
 const BYTE* expectedVurrentUVPtr = outBuffer + (ptrdiff_t)GetOutFrameSize();
 assert(expectedVurrentUVPtr == (BYTE *)dstUV);

#endif
}



This leads to the Y being correct and the amount of lines for U and V as well, but somehow U and V are not overlaid properly. There are two versions of it seemingly mirrored through the center vertical. Something similar but less visible for zeroing out V. So both of these are getting rendered at half the width ? Any tips appreciated :)


Fix :
Found the bug, I'm flipping VU not per pack but per block


if (pack % 2 == 0)



Should be


if (line % 2 == 0)