Recherche avancée

Sur d’autres sites (4743)

• Write seekable AAC audio stream into MP4 file with FFMPEG

  22 octobre 2017, par lex82

  I’m trying to write an AAC audio stream into an mp4 file using the FFMPEG libraries. I am using a custom IO context that writes directly to a socket so I have to set ioContext->seekable = 0. To make this work I had to add the "movflags" empty_moov and frag_keyframe when writing the header.

  After writing the output to a file on the other end of the socket, I can play the file in VLC or Windows Media Player. However, seeking to a specific position in the file is not working properly in both players. WMP also does not show the total duration and VLC only flashes it shortly when reaching the end of the audio.

  Is there a way to add more metadata when muxing so the players are able to treat the file as if it was not written as a stream ? Transfer via the socket is not interrupted abruptly, so I could write metadata at the end of the file. I also know the total duration in advance, so I could add it to the header of the file if it was possible. I cannot use the faststart flag because this would require output to a seekable file before writing to the socket.

  Update : I learned that I can set the duration in AVFormatContext and I can set nb_frames and avg_frame_rate in AVStream. However, it doesn’t solve my problem. When I set the codecContext flag AV_CODEC_FLAG_QSCALE, VLC seems to be able to estimate the total time. However, seeking still doesn’t work.

• Write seekable AAC audio stream into MP4 file with FFMPEG

  18 avril 2016, par lex82

  I’m trying to write an AAC audio stream into an mp4 file using the FFMPEG libraries. I am using a custom IO context that writes directly to a socket so I have to set ioContext->seekable = 0. To make this work I had to add the "movflags" empty_moov and frag_keyframe when writing the header.

  After writing the output to a file on the other end of the socket, I can play the file in VLC or Windows Media Player. However, seeking to a specific position in the file is not working properly in both players. WMP also does not show the total duration and VLC only flashes it shortly when reaching the end of the audio.

  Is there a way to add more metadata when muxing so the players are able to treat the file as if it was not written as a stream ? Transfer via the socket is not interrupted abruptly, so I could write metadata at the end of the file. I also know the total duration in advance, so I could add it to the header of the file if it was possible. I cannot use the faststart flag because this would require output to a seekable file before writing to the socket.

  Update : I learned that I can set the duration in AVFormatContext and I can set nb_frames and avg_frame_rate in AVStream. However, it doesn’t solve my problem. When I set the codecContext flag AV_CODEC_FLAG_QSCALE, VLC seems to be able to estimate the total time. However, seeking still doesn’t work.

• Increasing CPU usage over time in FFmpeg with Widevine DRM stream

  25 octobre 2024, par nabil fernandez kiker

  Increasing CPU usage over time in FFmpeg with __memset_avx2_unaligned_erms while processing DRM .mpd streams
I'm facing a problem where CPU usage gradually increases when using FFmpeg to process a DRM-protected DASH stream (.mpd with Widevine encryption). Initially, the CPU usage is low, but after around 2 hours, the usage doubles, and it keeps increasing over time.
I used perf to analyze what's happening, and this is what I see after a few hours :

  


  Overhead  Shared Object     Symbol
  25.57%  ffmpeg            [.] __memset_avx2_unaligned_erms
   9.28%  ffmpeg            [.] aes_encrypt
   8.25%  [kernel]          [k] clear_page_rep
   3.17%  [kernel]          [k] asm_exc_page_fault
   1.68%  [kernel]          [k] __handle_mm_fault
   1.38%  ffmpeg            [.] __memmove_avx_unaligned_erms
   1.14%  ffmpeg            [.] _aesni_ctr32_ghash_6x
   1.01%  ffmpeg            [.] malloc_consolidate


  


  Context
I am processing a Widevine DRM-protected DASH stream (.mpd) using FFmpeg to decrypt it and convert it into HLS segments. -cenc_decryption_key
The issue arises after a few hours, and it seems to center around the function __memset_avx2_unaligned_erms, which ends up using about 25% of the CPU after several hours.
The workload is running with FFmpeg built statically with OpenSSL, AVX2 support, and other necessary dependencies.

  


  Questions :
Why is __memset_avx2_unaligned_erms being called more frequently as time progresses, and why does the CPU usage keep rising ?
Could this be related to misaligned memory or an issue with the AVX2 SIMD implementation in FFmpeg or glibc ?
What strategies can I use to prevent this CPU usage increase in long-running DRM-protected stream processing ?
Should I consider disabling SIMD optimizations in FFmpeg for certain parts of the process ? If so, how can I do this without losing performance benefits ?
Any guidance or suggestions would be greatly appreciated, as I'm running out of ideas to resolve this issue.

  


  What I’ve tried :
Perf analysis : I've confirmed the problem seems related to __memset_avx2_unaligned_erms being called increasingly over time.
Memory buffer optimization : I've attempted to reuse memory buffers to avoid excessive memory allocation and initialization, but the issue persists.
Reducing memset calls : I've reduced the size of memory buffers, trying to limit the impact of memset, but CPU usage still increases after extended processing.