Recherche avancée

Sur d’autres sites (5679)

• avcodec/roqvideodec : Move transient GetByteContext to the stack

  30 août 2020, par Andreas Rheinhardt

  avcodec/roqvideodec : Move transient GetByteContext to the stack
  This avoids keeping potentially dangling pointers in the context,
  
  beautifies the code (by replacing "&ri->gb" by gb for every access to
  
  the GetByteContext) and also highlights the GetByteContext's short-lived
  
  nature better.
  Reviewed-by : Paul B Mahol <onemda@gmail.com>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavcodec/roqvideo.h
  • [DH] libavcodec/roqvideodec.c

• ffmpeg not reading stdin fast enough

  5 mars 2019, par Joshua Walsh

  I have a NodeJS program which launches ffmpeg (with child_process) and then provides realtime video data via stdin, using the pipe protocol.

  ffmpeg -nostdin -i pipe:0 -codec libx264 -preset veryfast -tune zerolatency -acodec aac -b:a 128k output/index.m3u8

  ffmpeg transcodes the video into h264 and muxes it into an HLS live stream.

  The issue that I have is that sometimes ffmpeg refuses to accept more input. The default behaviour of NodeJS is to buffer input until the child process can accept it, but after a while this causes my application to run out of memory.

  I tried a naive solution where if ffmpeg wasn’t able to read the input (if proc.stdin.write returns false) I would start discarding data until the drain event was raised on the stream, but this unsurprisingly led to badly degraded video output, with terrible artifacting.

  The nature of the source of the data makes it impossible for me to block, my application has to deal with it in realtime.

  ffmpeg is using only a fraction of the available resources on the system (35% CPU, 1% disk), so I’m not sure why it’s blocking stdin. If I specify a more demanding preset then it happily uses more CPU, so CPU speed shouldn’t be a limiting factor.

  Does anyone know why ffmpeg would be blocking stdin ? Is there a way I can tell ffmpeg to drop frames if it starts falling behind ?

• avformat/matroskaenc : Improve BlockAdditions

  20 novembre 2019, par Andreas Rheinhardt

  avformat/matroskaenc : Improve BlockAdditions
  8ffcc826 added support for muxing BlockAdditions with BlockAddID equal
  
  to one. The restriction to BlockAddID == 1 probably resulted from
  
  a limitation to what was needed ; yet over time this led to three
  
  occurences of "(side_data_size && additional_id == 1)". This commit
  
  changes this by setting side_data_size to 0 if additional_id != 1.
  It also stops hardcoding 1 for the value of BlockAddID to write ;
  
  but it still upholds the requirement that it is 1. See below.
  Despite BlockAddId actually having a default value of 1, it is still
  
  written, because until very recently (namely dbc50f8a) our demuxer
  
  used a wrong default value of 0.
  Furthermore, use put_ebml_binary() to write the BlockAdditional element.
  (The Matroska specifications have evolved and now the BlockAddID 1 is
  
  reserved for the codec (as described in the codec's codec mapping),
  
  BlockMore elements with BlockAddID > 1 are now of a more
  
  codec-independent nature and require a BlockAdditionalMapping in the
  
  track's TrackEntry. Given that this muxer does not support writing said
  
  BlockAdditionalMapping yet (actually, none have been defined yet), we
  
  have to uphold the requirement that BlockAddID == 1.)
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/matroskaenc.c