Recherche avancée

Sur d’autres sites (5286)

• Dreamcast Development Desktop

  28 mars 2011, par Multimedia Mike — Sega Dreamcast

  Some people are curious about what kind of equipment is required to program a Sega Dreamcast. This is my setup :

  
  
  

  It’s a bit overcomplicated. The only piece in that picture which doesn’t play a role in the Dreamcast development process is the scanner. The Eee PC does the heavy lifting of development (i.e., text editing and cross compilation) and uploads to the Dreamcast via a special serial cable. Those are the most essential parts and are really the only pieces necessary for a lot of algorithmic stuff (things that can be validated via a serial console). But then I have to go up a level where I output video. That’s where things get messy.

  
  
  

  The Mac Mini and giant monitor really just act as a glorified TV in this case. Ideally, it will be more than that. The DC outputs audio and video via composite cables to a Canopus DV capture bridge. That’s connected via FireWire to the external hard drive underneath the Mac Mini, which is connected to the Mac. Adobe Premiere Pro handles the DV capture / display.

  One day I hope to have something worthwhile to capture.

• FFmpeg playable MP4 segmented video from RTSP

  5 février 2021, par Michael Novotný

  I have problem with creating playable uncomplete MP4 file created from FFMPEG. In my case I have some infinite RTSP stream (h.264) from IP camera.
My target is record this stream to MP4 files for playback. If i use FFMPEG mp4 muxer, work correctly.

  


  /usr/bin/ffmpeg -progress pipe:5 -use_wallclock_as_timestamps 1 -analyzeduration 10000000 -probesize 10000000 -fflags +igndts -rtsp_transport tcp -hwaccel auto -loglevel warning -i rtsp://****:****@*******:****/ -y -an -vcodec copy -strict experimental -movflags frag_keyframe+empty_moov -f segment -segment_format mp4 -segment_format_options movflags=+faststart -segment_atclocktime 1 -reset_timestamps 1 -strftime 1 -segment_time 15 /Shinobi/videos/bWkwjTWdRt/Rm67cYyq50/test-%S.mp4


  


  FFMPEG will create one MP4 file which still increasing its size. If I try copy or simply open this (uncomplete, still increased ... of course :) ) file, it's correcly play. But it's still only one file ... still bigger and bigger. For long-term recording cam (few weeks) it's not good.
I want segment this stream to multiple smaller MP4 files (as you knows from another typical NVR systems). For example : segment for 30minutes.
I used "segment" muxer.

  


  /usr/bin/ffmpeg -progress pipe:5 -use_wallclock_as_timestamps 1 -analyzeduration 10000000 -probesize 10000000 -fflags +igndts -rtsp_transport tcp -hwaccel auto -loglevel warning -i rtsp://*****:****@*********:****/ -y -an -vcodec copy -strict -2 -movflags frag_keyframe+empty_moov -f mp4 -segment_atclocktime 1 -reset_timestamps 1 -strftime 1 -segment_list pipe:8 -segment_time 15 /Shinobi/videos/bWkwjTWdRt/Rm67cYyq50/test-%S.mp4


  


  It looks like work correctly. New file with defined mask is created every 30 minutes. If I try copy or simply open(and play) anyone "completed 30min segment file" it"s works correctly. Problem is with last file (more precisely : newest, still uncompleted last segment file) - it's not playable (moov atom not found).

  


  I Googled my problem many time with another keywords. I was try many my wonders. I readed FFMPEG documentation maybe 5times.

  


  Problem is with second passthroug which "segment muxer" do (which do -movflags +faststart .. for example). It's logicaly, second passthroug not be did in last(newest) file yet.

  


  Is there way to make it work ? If I want see time for 2-3 mins ago it's no possible wait up to 30minutes for "complete segment" ... and at the same time it is not possible to have a billion files with 2-3sec segments.
How did other NVR systems solve this ? Synology, Hikvision and more has in their file system recorded MP4 soubory which one of them is still uncompleted, still growing, but normaly PLAYABLE.

  


  A few last days I tried this with no success. I'am absolutely angry and sad. I hope that my text is understandable

  


  Thank you

  


  This options has no effect in my case (tried) :

  


  -movflags frag_keyframe+empty_moov

  


  -movflags faststart

  


  -movflags separate_moof

  


  -fragsize *** / -fragtime ***

  


  -strict -2 / -strict experimental

  


• avutil/mips : refactor msa SLDI_Bn_0 and SLDI_Bn macros.

  6 août 2019, par gxw

  avutil/mips : refactor msa SLDI_Bn_0 and SLDI_Bn macros.
  Changing details as following :
  
  1. The previous order of parameters are irregular and difficult to
  
     understand. Adjust the order of the parameters according to the
  
     rule : (RTYPE, input registers, input mask/input index/..., output registers).
  
     Most of the existing msa macros follow the rule.
  
  2. Remove the redundant macro SLDI_Bn_0 and use SLDI_Bn instead.
  Reviewed-by : Shiyou Yin <yinshiyou-hf@loongson.cn>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/mips/h264dsp_msa.c
  • [DH] libavcodec/mips/h264qpel_msa.c
  • [DH] libavcodec/mips/hevc_lpf_sao_msa.c
  • [DH] libavcodec/mips/hevcpred_msa.c
  • [DH] libavcodec/mips/hpeldsp_msa.c
  • [DH] libavcodec/mips/me_cmp_msa.c
  • [DH] libavcodec/mips/qpeldsp_msa.c
  • [DH] libavcodec/mips/vp8_mc_msa.c
  • [DH] libavcodec/mips/vp9_idct_msa.c
  • [DH] libavcodec/mips/vp9_lpf_msa.c
  • [DH] libavcodec/mips/vp9_mc_msa.c
  • [DH] libavutil/mips/generic_macros_msa.h