Recherche avancée

Sur d’autres sites (3511)

• Dreamcast Track Sizes

  1er mars 2015, par Multimedia Mike — Sega Dreamcast

  I’ve been playing around with Sega Dreamcast discs lately. Not playing the games on the DC discs, of course, just studying their structure. To review, the Sega Dreamcast game console used special optical discs named GD-ROMs, where the GD stands for “gigadisc”. They are capable of holding about 1 gigabyte of data.

  You know what’s weird about these discs ? Each one manages to actually store a gigabyte of data. Each disc has a CD portion and a GD portion. The CD portion occupies the first 45000 sectors and can be read in any standard CD drive. This area is divided between a brief data track and a brief (usually) audio track.

  The GD region starts at sector 45000. Sometimes, it’s just one humongous data track that consumes the entire GD region. More often, however, the data track is split between the first track and the last track in the region and there are 1 or more audio tracks in between. But the weird thing is, the GD region is always full. I made a study of it (click for a larger, interactive graph) :

  
  
  

  Some discs put special data or audio bonuses in the CD region for players to discover. But every disc manages to fill out the GD region. I checked up on a lot of those audio tracks that divide the GD data and they’re legitimate music tracks. So what’s the motivation ? Why would the data track be split in 2 pieces like that ?

  I eventually realized that I probably answered this question in this blog post from 4 years ago. The read speed from the outside of an optical disc is higher than the inside of the same disc. When I inspect the outer data tracks of some of these discs, sure enough, there seem to be timing-sensitive multimedia FMV files living on the outer stretches.

  One day, I’ll write a utility to take apart the split ISO-9660 filesystem offset from a weird sector.

• Why is the FindClass/JNI function behaving differently on nexus 5 and Honor Play ?

  17 août 2020, par Owl

  MobileFFmpeg v4.3.1LTS works on Honor Play, but doesn't work on Nexus 5. Why ?

  


  The build for Honor Play and nexus 5 is the same ->armeabi-v7a

  


  


  https://github.com/tanersener/mobile-ffmpeg/releases/tag/v4.3.1.LTS

  


  Nexus5 :enter image description here

  


  HonorPlay :enter image description here

  


  


  


  NDK = ndk-r14b

  


  


  


  JDK = jdk1.8.0_77

  


  


  I will ask the question immediately in English stackoverflow. Developing a game in Unreal Engine 4 v24.3. In the code itself there are only 2 lines that relate to MobileFFmpeg :

  


  Enabling the function :

  


  extern "C"
{
    int ffmpeg_execute(int argc, char** argv);
}


  


  Calling a function with ffmpeg parameters

  


  ffmpeg_execute(arg.size(), arg.data());


  


  Without mobile FFmpeg, the app on nexus 5 starts and works stably. When I start with FFmpeg, an error immediately appears and the app crashes :

  


  enter image description here

  


  The FindClass function does not work, the call itself is declared in mobile ffmpeg.c :

  


  /** Full name of the Config class */
const char *configClassName = "com/arthenica/mobileffmpeg/Config";


  


  ...

  


  /**
 * Called when 'mobileffmpeg' native library is loaded.
 *
 * @param vm pointer to the running virtual machine
 * @param reserved reserved
 * @return JNI version needed by 'mobileffmpeg' library
 */
jint JNI_OnLoad(JavaVM *vm, void *reserved) {
    JNIEnv *env;
    if ((*vm)->GetEnv(vm, (void**)(&env), JNI_VERSION_1_6) != JNI_OK) {
        LOGE("OnLoad failed to GetEnv for class %s.\n", configClassName);
        return JNI_FALSE;
    }

    jclass localConfigClass = (*env)->FindClass(env, configClassName);
    if (localConfigClass == NULL) {
        LOGE("OnLoad failed to FindClass %s.\n", configClassName);
        return JNI_FALSE;
    }
...


  


  I can't see what the FindClass(C++) function returns, Android Studio doesn't want to stop on the JNI_OnLoad(C++) function during debug.

  


  What are the assumptions why FindClass behavior is different on two phones ?

  


• Anomalie #4543 (Nouveau) : Accessibilité des chargements ajax (live regions)

  2 septembre 2020, par nicod _

  Suite à un audit de site par Temesis, il remonte que les attributs aria qu’on utilise sont mal placés.

  Je cite :

  Il semble qu’il y a un problème plus global avec l’utilisation des live region :
  Je rencontre à nouveau le div englobant div.ariaformprop qui possèdent les attributs

  aria-live
  aria-atomic
  aria-relevant

  Cette utilisation de ces attributs est erronée :

  elle ne donne pas le résultat probablement attendu
  le support d’aria-relevant dans les assistances technologiques n’est pas assuré

  Il est donc nécessaire de ne pas utiliser de live region sur une div englobante comme là.
  Il faut supprimer ces attributs et utiliser aria-live et aria-atomic avec parcimonie.

  J’ai regardé l’exemple que tu donnes sur spip.net également.

  L’exemple était : https://www.spip.net/spip.php?page=recherche&recherche=plugin&debut_articles=0#pagination_articles

  Cette prolifération d’aria-live + aria-atomic part probablement d’un bon sentiment, mais comme parfois avec l’accessibilité, le mieux est l’ennemi du bien.

  En positionnant ces attributs, avec ces valeurs, sur des div englobantes, cela génère dans les lecteurs d’écran la lecture automatique des contenus qui ont été mis à jour.

  Certes la lecture peut être interrompue par l’utilisateur, mais cela revient, à mon avis à imposer quelque chose qui n’a pas été forcément souhaité. De cette manière le propriétaire du site impose une expérience différente aux utilisateurs de lecteur d’écran.
  Ensuite, il faut bien entendu prendre en compte le contexte. Il pourrait arriver que ce comportement soit pertinent. Ce n’est pas le cas ici.

  Dans le cas de rechargement ajax, il faut étudier chaque cas et son contexte, mais le plus souvent le principe est :

  Ne pas utiliser ces attributs lorsqu’il n’y a pas d’interactions / rechargement ajax . Exemple sur un formulaire, cela n’a pas de sens : on rempli un form et puis on valide le form. A priori (si j’ai bien compris le fonctionnement) il n ’y a aucune raison d’utiliser de live region. En théorie, la présence de ces attributs s’il n’y a pas de rechargement ne devrait pas gêner. Mais certains lecteurs d’écran peuvent prendre des libertés par rapport aux spécifications et vocaliser des contenus tout de même. C’est pourquoi il faut être parcimonieux.

  Lorsqu’ils sont utiles et nécessaires, utiliser ces attributs pour informer d’un changement. Exemple : donner le nouveau nombre de résultats après utilisation de filtre. Mais il faut bien penser que dans plusieurs cas ils ne sont pas nécessaires, en effet, un bouton d’action doit être explicite avant qu’on appuie dessus. Donc par exemple : lorsque je demande à afficher la page 2 dans une pagination de résultat, il n’y a pas d’info à vocaliser automatiquement, le fait que le bouton dise "afficher la page 2" est suffisant, il serait superflu, voire gênant d’aller plus loin dans ce qui est vocalisé.

  Enfin, il faut gérer le focus clavier. Cet aspect est essentiel dès qu’il y a des interactions ajax, mais il dépend totalement du contexte. Et cet aspect est indépendant de la nécessité d’utiliser les live regions. Exemple : dans une série de filtre on va laisser le focus sur le filtre pour que l’utilisateur puisse parcourir la série de filtre. A contrario, dans une pagination (ou quand on a un bouton de type "afficher plus d’articles", dans des news ou dans une page de produits pour un site de e-commerce) on va déplacer le focus sur le 1er nouveau élément qui vient de s’afficher (la zone qui a été mise à jour).