Recherche avancée

Sur d’autres sites (3897)

• avformat/crypto : add seeking support on read

  30 août 2016, par Simon Hailes

  avformat/crypto : add seeking support on read
  cyrpto allows reading of data which has been aes-128-cbc encrypted given a key and an iv. But it did not handle filetypes which require seeking... e.g. it failed on an encrypted .mp4 file.
  example :
  
  take 25.mp4 created with :
  
  ffmpeg -f lavfi -i sine=frequency=1000:beep_factor=2:r=48000:duration=720.0 -f lavfi -i testsrc=duration=720.0:rate=25 -vcodec libx264 -cmp 22 -timecode 10:00:00:00 -r 25 -y out\25.mp4
  encrypt with :
  
  openssl enc -aes-128-cbc -K 12345678901234567890123456789012 -iv 12345678901234567890123456789012 -in 25.mp4 -out 25.enc
  
  then to transcode in ffmpeg :
  
  ffmpeg -key 12345678901234567890123456789012 -iv 12345678901234567890123456789012 -i crypto:25.enc -vcodec mpeg4 -r 25 -y 25dec.mp4
  prior to this modification, the transcode would fail.
  Note also :  crypto previously maked both reads and writes as streamed, which caused the whole file
  
  to be read before the transcode started.  Now, for read only, if the underlying layer is not marked as streamed,
  
  then crypto is not.  This should enable efficient reading of encrypted containers which require seeking.
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/crypto.c

• lavf/matroskaenc : use mkv_check_tag_name consistently

  6 septembre 2016, par Rodger Combs

  lavf/matroskaenc : use mkv_check_tag_name consistently
  Previously, we used a different list of checks when deciding whether to
  
  write a set of tags at all than we did when deciding whether to write an
  
  individual tag in the set. This resulted in sometimes writing an empty
  
  tag master and seekhead. Now we use mkv_check_tag_name everywhere, so
  
  if a dictionary is entirely composed of tags we skip, we don’t write a
  
  tag master at all.
  This affected the test file, since "language" was on one list but not
  
  the other, so we were writing an empty tag master there. The test hash
  
  is updated to reflect that change.
  

  • [DH] libavformat/matroskaenc.c
  • [DH] tests/fate/matroska.mak

• Recording from online stream and listening to it at the same time (ffmpeg / ffplay)

  28 juin 2016, par Konstantin

  Sometimes I like to record programmes from online radio channels, live or archived streams too. When there is no interesting actual programmes in the radios, I also would like listening to it at the same time while recording. I am using such command lines, which is called from Ruby script - to help parsing radios’ timetables / programme pages and constructing the proper URLs of archived programmes which usually contains some timecode, such as 20160616_083000.mp3, etc.
  So my command line to call from Ruby script looks like :

      programmes.each{|datepart,programme_length| 
  
        cmd=%Q{ffmpeg -y -i http://example.com/stream/#{datepart}.mp3 -t #{programme_length} -c:a libmp3lame -b:a 160k "#{fname}" -c copy -t #{programme_length} -f mp3 -f rtp rtp://127.0.0.1:8888}
  
        system cmd
  
  }

  It resides in a loop to record the previously parsed and selected programmes. Of cource the programmes are recorded properly and at the same time ffmpeg streams it as an mp3 rtp stream as well on localhost at the given port. In another terminal window I connect to the streamed data with one-liner as follows :

  while true; do ffplay -i rtp://127.0.0.1:8888 -autoexit; done

  I am using the -autoexit switch which should be stop playing the stream when it is ended and the "while" loop should be connect again to the new stream which is served by the programme recording "each" loop. Unfortunately it keeps playing after the end, and doesn’t initiate a new connection to the newly started stream. How to use ffplay properly to stop playing after rtp stream is ended and let it connect again to the new stream ?