Recherche avancée

Sur d’autres sites (5739)

• FFmpeg move overlay from one pixel coordinate to another

  22 mai 2015, par occvtech

  I’m trying to write a command within FFmpeg that will first overlay one video stream on top of another one. Then I want the overlayed video to move from one pixel coordinate at a known time, and end at another pixel coordinate at a later time.

  I’m comfortable with the basics of the -filter_complex, but I cannot figure out how to apply any arithmetic expressions - like the one’s referenced here : https://www.ffmpeg.org/ffmpeg-utils.html#Expression-Evaluation

  Here’s an example of something I’d like to accomplish.

  ffmpeg -i [INPUT1] -i [INPUT2] -filter_complex "[0:v][1:v]overlay=shortest=1:x=720:y=0:enable='between(t,10,20)'[overlay];...

  In this example the overlay is stationary at pixel coordinate 720x0 from the 10th second to the 20th second.

  However, Id like to have it move to a new location in a linear fashion and end at a different pixel coordinate.

  For example, during that 10 second overlay, I’d like to have it start at 720x0, but then end at 1000x100.

  Is this possible ?

• x264 & libavcodec

  25 janvier 2012, par moose

  After some considerable amount of time while trying to build the ffmpeg static library with the x264 encoder on Windows, I have spent some more time for writing some example with it.
  Of course, there are tons of "instructions" on how to build, how to use, bla bla... But, non of them works on Windows. I guess the Linux guys are in better position here. Now, the zillion dollars question is "What's the purpose of all that ?". Not only that this is useless on Windows, but I could have bought some third party library that actually works.

  If somebody is about to say "But, it works !". I must say, give me a working proof. I don't care about 200x100 at 10fps. I don't need H264 for that. Show me how to compress a single second of 1080i footage. It's H264, it's crossplatform (sounds funny if you ask me), Google is using it (it has to be perfect, right ?), some more hipe here...

• 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