Recherche avancée

Sur d’autres sites (9474)

• rtsp : Don’t warn about unparsed time ranges

  22 avril 2015, par Martin Storsjö

  rtsp : Don’t warn about unparsed time ranges
  This removes the error logging added in 4e54432164.
  This avoids warnings about "Invalid interval start specification ’now’"
  
  for live rtsp streams.
  We only try to parse some of the many valid values for time ranges
  
  in RTSP - the other ones are fully valid but not interesting for the
  
  use case in rtsp.c, so we shouldn’t warn about them.
  (Parsing the time ranges is needed to allow seeking, but e.g. setting
  
  the current realtime clock for the start time doesn’t make sense.
  
  av_parse_time has got a different mode for parsing absolute times
  
  as well, which can handle the special case "now", but that doesn’t
  
  make much sense for this particular use in rtsp.c.)
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavformat/rtsp.c

• ffmpeg removes dead space in video but not audio

  10 juillet 2015, par Peter Becich

  I’m transferring a VHS tape on Ubuntu with ffmpeg, somagic-capture, the line-in jack and an EasyCap dongle.

  There is a big issue with audio drift that, I believe, is caused by ffmpeg removing dead space from the video stream but not the audio stream.

  The capture utility creates a stream :

  somagic-capture --ntsc -c --luminance=2 --lum-aperture=3 \
  
  2> $SOMAGIC_LOG |

  Which is piped into ffmpeg. ffmpeg also captures from alsa :

   ffmpeg -pixel_format uyvy422 -s:v 720x480 \
  
  -framerate 29.97 -f rawvideo -i -  -f alsa -thread_queue_size 1024 \
  
  -i hw:0,0 -vf scale=w=640:h=480 -vcodec libx264 -preset ultrafast \
  
  -shortest -c:a libfdk_aac -b:a 256k $OUTFILE

  Is it true that ffmpeg by default removes dead space from a stream ?

  If so, would ffmpeg trim both streams even if only one is "dead" — suppose the video is momentarily blank while the audio is noisy.

  If not, are these two streams incompatible with each other ? Is the ALSA input (line-in jack) on a different clock than the EasyCap video dongle ?

  Input #0, rawvideo, from 'pipe:':
  
    Duration: N/A, start: 0.000000, bitrate: 165722 kb/s
  
      Stream #0:0: Video: rawvideo (UYVY / 0x59565955), uyvy422, 720x480, 
  
      165722 kb/s, 29.97 tbr, 29.97 tbn, 29.97 tbc
  
  Guessed Channel Layout for  Input Stream #1.0 : stereo
  
  
  
  Input #1, alsa, from 'hw:0,0':
  
    Duration: N/A, start: 1436492353.282796, bitrate: 1536 kb/s
  
    Stream #1:0: Audio: pcm_s16le, 48000 Hz, 2 channels, s16, 1536 kb/s

  I think the -shortest flag only concerns killing the ffmpeg process.

  My prior, more general question didn’t solve the problem : http://video.stackexchange.com/questions/14809/sync-up-ffmpeg-rawvideo-recording-and-audacity-alsa-recording

  Thanks for any advice !

  The full script :

  #!/bin/sh
  
  
  
  PIPE=/tmp/somagic-pipe
  
  OUTFILEDIR=~/easycap/Videos/
  
  LOGDIR=~/.somagic-log/
  
  NOW=`date +"%m_%d_%Y_%H_%M_%S"`
  
  
  
  OUTFILE=${OUTFILEDIR}fpv_${NOW}_video.mp4
  
  
  
  mkdir $LOGDIR
  
  
  
  FFMPEG_LOG=${LOGDIR}ffmpeg_video.log
  
  SOMAGIC_LOG=${LOGDIR}somagic_video.log
  
  MPLAYER_LOG=${LOGDIR}mplayer_video.log
  
  
  
  rm $PIPE >/dev/null 2>&1
  
  rm $OUTFILE >/dev/null 2>&1
  
  
  
  rm $FFMPEG_LOG
  
  rm $SOMAGIC_LOG
  
  rm $MPLAYER_LOG
  
  
  
  mkfifo $PIPE >/dev/null 2>&1
  
  
  
  somagic-capture --ntsc -c --luminance=2 --lum-aperture=3 \
  
  2> $SOMAGIC_LOG | ffmpeg -pixel_format uyvy422 -s:v 720x480 \
  
  -framerate 29.97 -f rawvideo -i -  -f alsa -thread_queue_size 1024 \
  
  -i hw:0,0 -vf scale=w=640:h=480 -vcodec libx264 -preset ultrafast \
  
  -shortest -c:a libfdk_aac -b:a 256k $OUTFILE
  
  
  
  rm $PIPE >/dev/null 2>&1 

  Modified from here : https://gist.github.com/Brick85/0b327ac2d3d45e23ed33

• gstreamer rtsp streaming chain with LGPL elements

  25 avril 2016, par user3612009

  The following chain seem to work well to stream video :

  gst-launch filesrc location=/home/manusha/Downloads/movies/<movie file="file">.mkv ! decodebin ! ffenc_mpeg4 bitrate=5000000 ! rtpmp4vpay mtu=1400 pt=96 ssrc=0 timestamp-offset=0 seqnum-offset=0 send-config=true ! udpsink host=127.0.0.1 port=5000
  
  </movie>

  This chain is able to receive the stream and play it :

  gst-launch udpsrc uri=udp://127.0.0.1:5000 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP4V-ES, profile-level-id=(string)1, config=(string)000001b001000001b58913000001000000012000c48d88007d0a041e1463000001b24c61766335322e3132332e30, payload=(int)96, ssrc=(uint)298758266, clock-base=(uint)3097828288, seqnum-base=(uint)63478" ! rtpmp4vdepay ! ffdec_mpeg4 ! autovideosink

  My problem is, both ffdec_mpeg4 and ffenc_mpeg4 are GPL licensed and will not suit my purpose because I need to redistribute them. I am lookiing for advice on alternative stream chains that I can form only with LGPL licensed elements. The streaming to be used only inside a LAN, but it need to support HD quality streaming.