Recherche avancée

Sur d’autres sites (4468)

• Is there a way to change the ffplay playback speed while running

  20 mai 2024, par richjhart

  I am trying to modify ffplay 7.0 to allow us to modify the playback speed while running. Our use-case only involves basic video-only mp4 files.

  


  We can set the playback speed with something like the following :

  


  ffplay -i ..\Video\SampleVideoLong.mp4 -vf "setpts=5.0*PTS" -loglevel debug -sync video

  


  But I don't know how to change that option "live" (note if I don't choose -sync video, it gets very laggy - but that's fine as our use-case is video only.

  


  I have tried the following (with just a fixed rate at the moment) :

  


          {
            static double l_CurrentSpeed = 1.0;
            double l_NewSpeed = 2.0;
            double l_Diff = l_NewSpeed / l_CurrentSpeed;
            double l_ClockSpeed = cur_stream->extclk.speed;
            double l_NewClockSpeed = l_ClockSpeed * l_Diff;
            av_log(NULL, AV_LOG_DEBUG,
                "Changing speed from %f to %f\n",
                l_ClockSpeed, l_NewClockSpeed
                );

            set_clock_speed(&cur_stream->vidclk, l_NewClockSpeed);
            //set_clock(&cur_stream->vidclk, l_NewClockSpeed, cur_stream->extclk.serial);
            l_CurrentSpeed = l_NewSpeed;
        }


  


  I've set both the pts (set_clock()) and the "speed" (set_clock_speed()), but neither of these had any effect.

  


  Would I need to something extra, or is there a way to update the setpts expression in the video filter from ffplay ?

  


  Note the metadata of the file we are trying with is :

  


  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '..\Video\SampleVideoLong.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2mp41
    encoder         : Lavf61.1.100
  Duration: 00:18:10.56, start: 0.160000, bitrate: 1755 kb/s
  Stream #0:0[0x1](und), 1, 1/90000: Video: mpeg2video (Main), 1 reference frame (mp4v / 0x7634706D), yuv420p(tv, bt709, progressive, left), 1920x1080 [SAR 1:1 DAR 16:9], 0/1, 1754 kb/s, 25 fps, 25 tbr, 90k tbn (default)
      Metadata:
        handler_name    : VideoHandler
        vendor_id       : [0][0][0][0]
        encoder         : XDCAM EX 1080p25
      Side data:
        cpb: bitrate max/min/avg: 0/0/0 buffer size: 278528 vbv_delay: N/A


  


  I believe the files we'll be using should have identical or similar metadata.

  


• avutil/eval : add function to track variable use

  17 novembre 2019, par Gyan Doshi

  avutil/eval : add function to track variable use
  1)Some filters allow cross-referenced expressions e.g. x=y+10. In
  
  such cases, filters evaluate expressions multiple times for
  
  successful evaluation of all expressions. If the expression for one or
  
  more variables contains a RNG, the result may vary across evaluation
  
  leading to inconsistent values across the cross-referenced expressions.
  2)A related case is circular expressions e.g. x=y+10 and y=x+10 which
  
  cannot be succesfully resolved.
  3)Certain filter variables may only be applicable in specific eval modes
  
  and lead to a failure of evaluation in other modes e.g. pts is only
  
  relevant for frame eval mode.
  At present, there is no reliable means to identify these occurrences and
  
  thus the error messages provided are broad or inaccurate. The helper
  
  function introduced - av_expr_count_vars - allows developers to identify
  
  the use and count of variables in expressions and thus tailor the error
  
  message, allow for a graceful fallback and/or decide evaluation order.
  

  • [DH] libavutil/eval.c
  • [DH] libavutil/eval.h
  • [DH] libavutil/version.h

• avcodec/wnv1 : Use LE bitstream reader, avoid copying packet, fix memleak

  29 août 2020, par Andreas Rheinhardt

  avcodec/wnv1 : Use LE bitstream reader, avoid copying packet, fix memleak
  The Winnov WNV1 format is designed for a little-endian bitstream reader ;
  
  yet our decoder reversed every byte bitwise (in a buffer only
  
  allocated for this purpose) to use a big-endian bitstream reader. This
  
  commit stops this.
  Two things needed to be done to achieve this : The codes in the table used
  
  to initialize a VLC reader needed to be reversed bitwise (when
  
  initializing a VLC in LE mode, it is expected that the first bit to be
  
  read is in the least significant bit ; with BE codes the first bit to be
  
  read is the most significant bit of the code) and the following
  
  expression needed to be adapted :
  ff_reverse[get_bits(&w->gb, 8 - w->shift)]
  But this is easy : When only the bits read are reversed, they coincide
  
  with what a little-endian bitstream reader reads that reads the
  
  original, not-reversed data. But ff_reverse always reverses the full
  
  eight bits and this also performs a shift by (8 - (8 - w->shift)) on top
  
  of reversing the bits read. So the above line needs to be changed to
  get_bits(&w->gb, 8 - w->shift) << w->shift
  and this also shows why the variable shift is named the way it is.
  Finally, this also fixes a hypothetical memleak : For gigantic packets,
  
  initializing a GetBitContext can fail and in this case, the buffer
  
  containing the reversed data would leak.
  Reviewed-by : Paul B Mahol <onemda@gmail.com>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavcodec/wnv1.c