Recherche avancée

Sur d’autres sites (5846)

• Anomalie #3647 : #INTRODUCTION + propre sous PHP7

  26 février 2016, par Ivan Lewkowitz

  Hello,

  - Pour la première balise [(#INTRODUCTION800|liens_ouvrants|propre)], je viens de retester et elle fonctionne comme ça. L’article a changé depuis la dernière fois, ce qui me laisse penser que le contenu a pu influencer. A vérifier… mais bon.

  - Regarde plus en détail la deuxième balise que j’utilise en survol dans une boucle où je liste les 3 derniers articles de certaines rubriques.
  

  [(#TITRE|supprimer_numero|rtrim’. ’)]

  Dans les trois résultats qui s’affichent, le premier et le troisième fonctionnent mais pas le deuxième (voir capture ci joint).
  Plus précisément, le deuxième affiche l’intro en survol tant que je coupe à 290 : [(#INTRODUCTION290|supprimer_tags|attribut_html)]
  mais si je passe à [(#INTRODUCTION291|supprimer_tags|attribut_html)] (ou plus), ça ne marche plus.

  Les deux autres intro au dessus et en dessous marchent tout le temps !

  

  Le code du texte de l’article qui déconne est :
  

  Le petit fils de Kim Il-sung est à la tête d’un régime militarisé dont l’arme nucléaire constitue le gage de sa survie. Toujours aux prises avec des difficultés alimentaires il comprend mal la logique de profit qui sous tend les investissements étrangers.

  
  

  Après le test nucléaire nord-coréen du 6 janvier, le scénario des réactions internationales qui se répète depuis 2006 n’a pas varié, sauf que, pour la dernière expérience en date, Pyongyang affirme avoir franchi le cap technologique de la fusion ce qui ajoute beaucoup à la sidération internationale, la puissance théorique d’un tel engin pouvant être 1000 fois supérieure à celle d’une bombe A classique. Mais pour l’heure, les premières réponses de la communauté internationale sont symétriques de celles qui suivirent le dernier test de 2013.

  Rien de spécial dans le texte, à part les accents de la langue française. Comme tu peux le voir sur l’image 2, j’ai même des intros contenant du chinois qui s’affichent sans problème.

  

• movenc : Get rid of frag_start

  12 août 2021, par Hu Weiwen

  movenc : Get rid of frag_start
  "frag_start" is redundant, and every occurance can be replaced with cluster[0].dts - start_dts
  The proof of no behaviour changes : (All line number below is based on commit bff7d662d728)
  "frag_start" is read at 4 place (with all possible call stacks) :
  mov_write_packet
  
    ...
  
    mov_flush_fragment
  
      mov_write_moof_tag
  
        mov_write_moof_tag_internal
  
          mov_write_traf_tag
  
            mov_write_tfxd_tag (#1)
  
            mov_write_tfdt_tag (#2)
  
        mov_add_tfra_entries (#3)
  
        mov_write_sidx_tags
  
          mov_write_sidx_tag (#4)
  mov_write_trailer
  
    mov_auto_flush_fragment
  
      mov_flush_fragment
  
        ... (#1 #2 #3 #4)
  
    mov_write_sidx_tags
  
      mov_write_sidx_tag (#4)
  
    shift_data
  
      compute_sidx_size
  
        get_sidx_size
  
          mov_write_sidx_tags
  
            mov_write_sidx_tag (#4)
  All read happens in "mov_write_trailer" and "mov_write_moof_tag". So we need to prove no behaviour change in these two
  
  functions.
  Condition 1 : for every track that have "trk->entry == 0", trk->frag_start == trk->track_duration.
  Condition 2 : for every track that have "trk->entry > 0", trk->frag_start == trk->cluster[0].dts - trk->start_dts.
  Definition 1 : "Before flush" means just before the invocation of "mov_flush_fragment", except for the auto-flush case in
  
  "mov_write_single_packet", which means before L5934.
  Lemma 1 : If Condition 1 & 2 is true before flush, Condition 1 & 2 is still true after "mov_flush_fragment" returns.
      Proof :
  
      No update to the tracks that have "trk->entry == 0" before flushing, so we only consider tracks that have "trk->entry > 0" :
      Case 1 : !moov_written and moov will be written in this iteration
  
          trk->entry = 0                                                                    L5366
  
          trk->frag_start == trk->cluster[0].dts - trk->start_dts                           Lemma condition
  
          trk->frag_start += trk->start_dts + trk->track_duration - trk->cluster[0].dts ;    L5363
  
          So trk->entry == 0 && trk->frag_start == trk->track_duration
  
      Case 2 : !moov_written and moov will NOT be written in this iteration
  
          nothing changed
  
      Case 3 : moov_written
  
          trk->entry = 0                                                                    L5445
  
          trk->frag_start == trk->cluster[0].dts - trk->start_dts                           Lemma condition
  
          trk->frag_start += trk->start_dts + trk->track_duration - trk->cluster[0].dts ;    L5444
  
          So trk->entry == 0 && trk->frag_start == trk->track_duration
      Note that trk->track_duration may be updated for the tracks that have "trk->entry > 0" (mov_write_moov_tag will
  
      update track_duration of "tmcd" track, but it must have 1 entry). But in all case, trk->frag_start is also updated
  
      to consider the new value.
  Lemma 2 : If Condition 1 & 2 is true before "ff_mov_write_packet" invocation, Condition 1 & 2 is still true after it returns.
      Proof :
  
      Only the track corresponding to the pkt is updated, and no update to relevant variables if trk->entry > 0 before invocation.
  
      So we only need to prove "trk->frag_start == trk->cluster[0].dts - trk->start_dts" after trk->entry increase from 0 to 1.
      Case 1 : trk->start_dts == AV_NOPTS_VALUE
  
          Case 1.1 : trk->frag_discont && use_editlist
  
              trk->cluster[0].dts = pkt->dts        at L5741
  
              trk->frag_start = pkt->pts            at L5785
  
              trk->start_dts = pkt->dts - pkt->pts  at L5786
  
              So trk->frag_start == trk->cluster[0].dts - trk->start_dts
  
          Case 1.2 : trk->frag_discont && !use_editlist
  
              trk->cluster[0].dts = pkt->dts        at L5741
  
              trk->frag_start = pkt->dts            at L5790
  
              trk->start_dts = 0                    at L5791
  
              So trk->frag_start == trk->cluster[0].dts - trk->start_dts
  
          Case 1.3 : !trk->frag_discont
  
              trk->cluster[0].dts = pkt->dts        at L5741
  
              trk->frag_start = 0                   init
  
              trk->start_dts = pkt->dts             at L5779
  
              So trk->frag_start == trk->cluster[0].dts - trk->start_dts
  
      Case 2 : trk->start_dts != AV_NOPTS_VALUE
  
          Case 2.1 : trk->frag_discont
  
              trk->cluster[0].dts = pkt->dts                at L5741
  
              trk->frag_start = pkt->dts - trk->start_dts   at L5763
  
              So trk->frag_start == trk->cluster[0].dts - trk->start_dts
  
          Case 2.2 : !trk->frag_discont
  
              trk->cluster[0].dts = trk->start_dts + trk->track_duration  at L5749
  
              trk->track_duration == trk->frag_start                      Lemma condition
  
              So trk->frag_start == trk->cluster[0].dts - trk->start_dts
  Lemma 3 : Condition 1 & 2 is true in all case before and after "ff_mov_write_packet" invocation, before flush and after
  
           "mov_flush_fragment" returns.
      Proof : All updates to relevant variable happen either in "ff_mov_write_packet", or during flush. And Condition 1 & 2
  
             is true initially. So with lemma 1 & 2, we can prove this use induction.
  Noticed that all read of "frag_start" only happen in "trk->entry > 0" branch. Now we need to prove Condition 2 is true
  
  before each read.
  Because no update to variables relevant to Condition 2 between "before flush" and "mov_write_moof_tag" invocation, we
  
  can conclude Condition 2 is true before every invocation of "mov_write_moof_tag". No behaviour change in
  
  "mov_write_moof_tag" is proved.
  In "mov_write_trailer", No update to relevant variables after the last flush and before the invocation of
  
  "mov_write_sidx_tag". So no behaviour change to "mov_write_trailer" is proved.
  Q.E.D.
  Signed-off-by : Hu Weiwen <sehuww@mail.scut.edu.cn>
  
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavformat/movenc.c
  • [DH] libavformat/movenc.h

• find matching files using a.bat script and assign them to a variable ?

  2 octobre 2019, par A Person

  I am trying to assign a file to a variable in batch-file and then also assign anoter 2 files into anoter variable.

  However, i am having an issue.

  From research, i found how i can do the assigning but does anyone know how i can do the below.

  From a folder or text file (either is fine) find the .m2v video file and assign that to Var1 then find matching audio in .wav and put that in Var2 and the third is also an audio .wav with mathcing name and assign that to Var3.

  Problem i am having is that trying to find the matching 2 audio file to the video.

  The video file is named as PAV_PRG_13683Highc450277201906251802090353.m2v

  Audio 1 is : PAV_PRG_13683High01c450211201906251802090376.wav

  Audio 2 is : PAV_PRG_13683High00c450211201906251802090368.wav

  the file name matches until it sees the word High. Everything after High is not needed and is random string so trying to match is an issue.

  is there a way to find the match by comparing everything before High.

  Also as i will be using the variable and putting them through ffmpeg to merge, is there way to do it so that when the ffmpeg command is done, it moves to the next matching files and assigns them to the variable.

  files are store in 2 folders

  One folder has all the video files *.m2v

  and another folder has all the *.wav audio files in pairs of 2. Each video has exactly 2 audios (left right audio)

  is there any hel pon this subject, i have already come up empty in my research and have been checking for this over the last week spent almost 30 hours.