Recherche avancée

Sur d’autres sites (7849)

• lavc : replace internal use of AV_CODEC_CAP_AUTO_THREADS with an internal cap

  9 mars 2021, par Anton Khirnov

  lavc : replace internal use of AV_CODEC_CAP_AUTO_THREADS with an internal cap
  AV_CODEC_CAP_AUTO_THREADS was originally added in b4d44a45f9a to mark
  
  codecs that spawn threads internally and are able to select an optimal
  
  threads count by themselves (all such codecs are wrappers around
  
  external libraries). It is used by lavc generic code to check whether it
  
  should handle thread_count=0 itself or pass the zero directly to the
  
  codec implementation. Within this meaning, it is clearly supposed to be
  
  an internal cap rather than a public one, since from the viewpoint of a
  
  libavcodec user, lavc ALWAYS handles thread_count=0. Whether it happens
  
  in the generic code or within the codec internals is not a meaningful
  
  difference for the caller.
  External aspects of this flag will be dealt with in the following
  
  commit.
  

  • [DH] libavcodec/internal.h
  • [DH] libavcodec/libaomdec.c
  • [DH] libavcodec/libaomenc.c
  • [DH] libavcodec/libdav1d.c
  • [DH] libavcodec/libdavs2.c
  • [DH] libavcodec/libkvazaar.c
  • [DH] libavcodec/libopenh264enc.c
  • [DH] libavcodec/librav1e.c
  • [DH] libavcodec/libsvtav1.c
  • [DH] libavcodec/libuavs3d.c
  • [DH] libavcodec/libvpxdec.c
  • [DH] libavcodec/libvpxenc.c
  • [DH] libavcodec/libx264.c
  • [DH] libavcodec/libx265.c
  • [DH] libavcodec/libxavs.c
  • [DH] libavcodec/libxavs2.c
  • [DH] libavcodec/pthread.c
  • [DH] libavcodec/utils.c

• Pipe opencv frames into ffmpeg

  25 juin 2023, par Dmytro Soltusyuk

  I am trying to pipe opencv frames into ffmpeg, but it does not work.

  


  After the research, I found this answer (https://stackoverflow.com/a/62807083/10676682) to work the best for me, so I have the following :

  


  def start_streaming_process(rtmp_url, width, height, fps):
    # fmt: off
    cmd = ['ffmpeg',
           '-y',
           '-f', 'rawvideo',
           '-vcodec', 'rawvideo',
           '-pix_fmt', 'bgr24',
           '-s', "{}x{}".format(width, height),
           '-r', str(fps),
           '-i', '-',
           '-c:v', 'libx264',
           '-pix_fmt', 'yuv420p',
           '-preset', 'ultrafast',
           '-f', 'flv',
           '-flvflags', 'no_duration_filesize',
           rtmp_url]
    # fmt: on

    return subprocess.Popen(cmd, stdin=subprocess.PIPE)


  


  def main():
    width, height, fps = get_video_size(SOURCE_VIDEO_PATH)
    streaming_process = start_streaming_process(
        TARGET_VIDEO_PATH,
        width,
        height,
        fps,
    )

    model = load_yolo(WEIGHTS_PATH)
    frame_iterator = read_frames(video_source=SOURCE_VIDEO_PATH)
    processed_frames_iterator = process_frames(
        model, frame_iterator, ball_target_area=400
    )

    for processed_frame in processed_frames_iterator:
        streaming_process.communicate(processed_frame.tobytes())

    streaming_process.kill()


  


  processed_frame here is an annotated OpenCV frame.

  


  However, after I do my first streaming_process.communicate call, the ffmpeg process exits with code 0 (meaning everything was ok), but it is not. I can not feed the rest of the frames into ffmpeg, because the process exited.

  


  Here are the logs :

  


  Input #0, rawvideo, from 'fd:':
  Duration: N/A, start: 0.000000, bitrate: 663552 kb/s
  Stream #0:0: Video: rawvideo (BGR[24] / 0x18524742), bgr24, 1280x720, 663552 kb/s, 30 tbr, 30 tbn
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
[libx264 @ 0x132e05570] using cpu capabilities: ARMv8 NEON
[libx264 @ 0x132e05570] profile High, level 3.1, 4:2:0, 8-bit
[libx264 @ 0x132e05570] 264 - core 164 r3095 baee400 - H.264/MPEG-4 AVC codec - Copyleft 2003-2022 - h
ttp://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme
=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 
fast_pskip=1 chroma_qp_offset=-2 threads=15 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 inter
laced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=
1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbt
ree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, flv, to 'rtmp://global-live.mux.com:5222/app/9428e064-e5d3-0bee-dc67-974ba53ce164':
  Metadata:
    encoder         : Lavf60.3.100
  Stream #0:0: Video: h264 ([7][0][0][0] / 0x0007), yuv420p(tv, progressive), 1280x720, q=2-31, 30 fps
, 1k tbn
    Metadata:
      encoder         : Lavc60.3.100 libx264
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
frame=    1 fps=0.0 q=29.0 Lsize=      41kB time=00:00:00.00 bitrate=N/A speed=   0x    eed=N/A    
video:40kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.678311%
[libx264 @ 0x132e05570] frame I:1     Avg QP:25.22  size: 40589
[libx264 @ 0x132e05570] mb I  I16..4: 37.7% 33.4% 28.9%
[libx264 @ 0x132e05570] 8x8 transform intra:33.4%
[libx264 @ 0x132e05570] coded y,uvDC,uvAC intra: 51.1% 53.2% 14.4%
[libx264 @ 0x132e05570] i16 v,h,dc,p: 32% 38% 20% 10%
[libx264 @ 0x132e05570] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 36% 28%  3%  2%  2%  3%  3%  6%
[libx264 @ 0x132e05570] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 37% 17%  4%  4%  4%  5%  4%  7%
[libx264 @ 0x132e05570] i8c dc,h,v,p: 46% 37% 12%  4%
[libx264 @ 0x132e05570] kb/s:9741.36


  


  That's all. Exit code 0.

  


• lavc : rename AV_CODEC_CAP_AUTO_THREADS->AV_CODEC_CAP_OTHER_THREADS

  9 mars 2021, par Anton Khirnov

  lavc : rename AV_CODEC_CAP_AUTO_THREADS->AV_CODEC_CAP_OTHER_THREADS
  This cap is currently used to mark multithreading-capable codecs that
  
  wrap external libraries with their own multithreading code. The name is
  
  highly confusing for our API users, since libavcodec ALWAYS handles
  
  thread_count=0 (see commit message in previous commit). Therefore rename
  
  the cap and update its documentation to make its meaning clear.
  The old name is kept deprecated until next+1 major bump.
  

  • [DH] doc/APIchanges
  • [DH] fftools/cmdutils.c
  • [DH] libavcodec/codec.h
  • [DH] libavcodec/libaomdec.c
  • [DH] libavcodec/libaomenc.c
  • [DH] libavcodec/libdav1d.c
  • [DH] libavcodec/libdavs2.c
  • [DH] libavcodec/libkvazaar.c
  • [DH] libavcodec/libopenh264enc.c
  • [DH] libavcodec/librav1e.c
  • [DH] libavcodec/libsvtav1.c
  • [DH] libavcodec/libuavs3d.c
  • [DH] libavcodec/libvpxdec.c
  • [DH] libavcodec/libvpxenc.c
  • [DH] libavcodec/libx264.c
  • [DH] libavcodec/libx265.c
  • [DH] libavcodec/libxavs.c
  • [DH] libavcodec/libxavs2.c
  • [DH] libavcodec/version.h