Recherche avancée
Autres articles (32)
-
La file d’attente de SPIPmotion
28 novembre 2010, parUne file d’attente stockée dans la base de donnée
Lors de son installation, SPIPmotion crée une nouvelle table dans la base de donnée intitulée spip_spipmotion_attentes.
Cette nouvelle table est constituée des champs suivants : id_spipmotion_attente, l’identifiant numérique unique de la tâche à traiter ; id_document, l’identifiant numérique du document original à encoder ; id_objet l’identifiant unique de l’objet auquel le document encodé devra être attaché automatiquement ; objet, le type d’objet auquel (...) -
Personnaliser les catégories
21 juin 2013, parFormulaire de création d’une catégorie
Pour ceux qui connaissent bien SPIP, une catégorie peut être assimilée à une rubrique.
Dans le cas d’un document de type catégorie, les champs proposés par défaut sont : Texte
On peut modifier ce formulaire dans la partie :
Administration > Configuration des masques de formulaire.
Dans le cas d’un document de type média, les champs non affichés par défaut sont : Descriptif rapide
Par ailleurs, c’est dans cette partie configuration qu’on peut indiquer le (...) -
Contribute to documentation
13 avril 2011Documentation is vital to the development of improved technical capabilities.
MediaSPIP welcomes documentation by users as well as developers - including : critique of existing features and functions articles contributed by developers, administrators, content producers and editors screenshots to illustrate the above translations of existing documentation into other languages
To contribute, register to the project users’ mailing (...)
Sur d’autres sites (6778)
-
AVFrame in AV_PIX_FMT_YUV420P format to H*W*3 data buffer conversion using sws_scale not accurate ?
13 février 2024, par user3133806I have an AVFrame that is in YUV420 format and I am trying to convert to packed RGB in a data buffer :


// Allocate enough for 8 bits per color in RGB.
 // Note that I want packed, not planar. i.e. RGBRGBRGB...
 // Each pixel is 3 bytes of RGB in row-major order
 buffer = new unsigned char[frame->height * frame->width * 3];

 enum AVPixelFormat frameFormat =
 static_cast<enum avpixelformat="avpixelformat">(frame->format);

 // Make sure the input is in the expected format.
 CHECK_EQ(frameFormat, AV_PIX_FMT_YUV420P);

 SwsContext* swsContext = sws_getContext(
 frame->width,
 frame->height,
 frameFormat,
 frame->width,
 frame->height,
 AV_PIX_FMT_RGB24,

 // I played around with these flags but could not get an accurate image
 SWS_BICUBIC | SWS_ACCURATE_RND,
 nullptr,
 nullptr,
 nullptr);

 // My understanding is that because I am using packed format, not planar
 // I only need to fill in the first pointer.
 unsigned char* out_planes[4];
 out_planes[0] = buffer;
 out_planes[1] = nullptr;
 out_planes[2] = nullptr;
 out_planes[3] = nullptr;

 sws_scale(
 swsContext,
 frame->data,
 frame->linesize,
 0,
 frame->height,
 &out_planes,

 // My understanding is that the stride of each plane is frame->width * 3
 (const int[4]){frame->width * 3, 0, 0, 0});
 sws_freeContext(swsContext);

</enum>

This code does produce an image but the image appears to be wrong.


On a 300x200 video, the right few columns are wrong.


On a bigger resolution video the image seems correct, but on a smaller video it is not :






EDIT : It appears this is a bug in sws_scale (bug or expected feature). Turning off vector instructions causes it to work as expected :


// Adding this line before sws_scale causes the images to be bit exact.
av_set_cpu_flags_mask(0);


I got that idea from this answer on SO : Turn off sw_scale conversion to planar YUV 32 byte alignment requirements


-
Révision 18371 : Report de r18366 :
22 août 2011, par cedric -Manque dans l’analyseur de DTD : il ne verifie pas qu’un attribut de type NMTOKEN ou NMTOKENS ne contient que des noms. Utile pour certains attributs des balises d’en-tete dans la DTD XHTML Basic 1.1, mais curieusement pas pour l’attribut "class" qui est clairement un NMTOKENS pourtant. (...)
-
VP9 encoding limited to 4 threads ?
30 décembre 2016, par kellerkindtI am considering to use VP9 to encode my BluRays in the future, since its an open source codec. But I cannot get Handbrake or ffmpeg use more than 50% (4) of my (8) cores. The encoding time is therefore much worse than x264/5 which uses all cores.
In Handbrake I just set encoder to VP9 and CQ19. There is no difference if I add "threads 8", "threads 16" or "threads 64" in the parameters field.
Testing ffmpeg in the command line ("-c:v libvpx-vp9 -crf 19 -threads 16 -tile-columns 6 -frame-parallel 1 -speed 0") also does not use any more cpu threads.
Is the current encoder not capable of encoding on more than 4 threads or am I doing something wrong ?
- Linux Mint 18
- handbrake 0.10.2+ds0-2build1
- ffmpeg 2.8.10-0ubuntu0.16.04.1
- libvpx3 1.5.0-2ubuntu1
Syndiquer tout le site
