
Recherche avancée
Autres articles (48)
-
Submit bugs and patches
13 avril 2011Unfortunately a software is never perfect.
If you think you have found a bug, report it using our ticket system. Please to help us to fix it by providing the following information : the browser you are using, including the exact version as precise an explanation as possible of the problem if possible, the steps taken resulting in the problem a link to the site / page in question
If you think you have solved the bug, fill in a ticket and attach to it a corrective patch.
You may also (...) -
Submit enhancements and plugins
13 avril 2011If you have developed a new extension to add one or more useful features to MediaSPIP, let us know and its integration into the core MedisSPIP functionality will be considered.
You can use the development discussion list to request for help with creating a plugin. As MediaSPIP is based on SPIP - or you can use the SPIP discussion list SPIP-Zone. -
Les autorisations surchargées par les plugins
27 avril 2010, parMediaspip core
autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs
Sur d’autres sites (6282)
-
lavc : replace internal use of AV_CODEC_CAP_AUTO_THREADS with an internal cap
9 mars 2021, par Anton Khirnovlavc : 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 SoltusyukI 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 Khirnovlavc : 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