Recherche avancée

Sur d’autres sites (4581)

• libfdk-aacdec : Reduce the default decoder delay by one frame

  4 juillet 2014, par Omer Osman

  libfdk-aacdec : Reduce the default decoder delay by one frame
  The default error concealment method if none is set via
  
  aacDecoder_SetParam(AAC_CONCEAL_METHOD) is set in
  
  CConcealment_InitCommonData within the fdk-aac library
  
  and is set to Energy Interpolation. This method requires one frame
  
  delay to the output. To reduce the default decoder output delay and
  
  avoid missing the last frame in file based decoding, use Noise
  
  Substitution as the default concealment method.
  Signed-off-by : Omer Osman <omer.osman@iis.fraunhofer.de>
  
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavcodec/libfdk-aacdec.c
  • [DH] libavcodec/version.h

• How to record a livestream in ffmpeg or gstreamer and split the files without skipping or duplicating frames

  15 décembre 2020, par Blake Cochrane

  Can somone please recommend a solution for safely recording a live stream to a file that would not produce a corrupted file if the system was unsavely shut down.

  


  I am starting on a project using a battery powered Raspberry Pi 4B.
I am using GStreamer to use the ASIC for Raw Pi camera to h.264 compression to create a RTSP/HLS/RTMP stream.
I need to continuosly record the livestream to a file on the Pi without any duplicate & missing frames or transcoding - eg using -vcodec copy.
As the Pi is battery powered, it can be unsafely shut down randomly when the battery is out of energy.
I know that if a mp4 container isn't 'finalised' with the moov atom before the file finishes writing which would leave the file corrupted/unrepairable and unplayable.
So if I have an mp4 recording of 6 hours that is corrupted and unfixable that is a problem.
My idea was to split the recording to a new file after x amount of minutes or frames or bytes as losing the last few minutes is not so bad as to lose hours of recordings.
I would need to set the last frame in the old file as the previous frame to the next I frame (starting frame) in the new file as a h.264 stream can only start on an I frame.

  


  So it would go like this.
file 1
| Frame |0001|I|
| --- | --- | --- |
|Frame|0002|P|
|Frame|0003|B|
...
| Frame |1524|B|
| --- | --- | --- |
| Frame |1525|P|

  


  file 2
| Frame |1526|I|
| --- | --- | --- |
| Frame |1527|B|

  


  Then all of the split files can be appended to each other without transcoding in ffmpeg.
I don't need to record the live stream directly to an mp4, whatever container it is in can be converted to an mp4 when appending the split files.

  


  There is a python script of the Raspberry pi that accomplishes all of this but it can not be used for a live stream multicast as the Pi camera can not be accessed by more than one process at a time.
Unless there is a way to live stream the latest frames in an mp4 file that is continiously being recorded to, I am stuck.

  


• Installer flvtool++

  22 août 2011

  Flvtool++ développé par Facebook est beaucoup plus rapide que Flvtool2 auparavant installé car il est écrit en C alors que Flvtool2 est en Ruby.

  Pour gagner en performance, il est préférable d’utiliser flvtool++ pour ajouter les métadonnées aux fichiers flv.

  Qui plus est, apparemment flvtool++ gère les videos très longue contrairement à flvtool2.

  On installera donc flvtool++ en plus de flvtool2 dans un premier temps afin de tester partout son bon fonctionnement.

  Tutoriel d’installation : http://technique.arscenic.org/compi...