Recherche avancée

Sur d’autres sites (11877)

• Error encountered during encoding with 1 thread and decoding with multiple threads using FFmpeg in C

  17 mai 2023, par Rachel

  I'm currently working on a project where I'm using FFmpeg in C programming language for encoding and decoding video. I have configured the encoder to use 1 thread and the decoder to use multiple threads (specifically, 23 threads). However, when I run the code, I encounter the following error :

  


  avcodec_receive_frame failure - Resource temporarily unavailable

  


  Here are the relevant code snippets :

  


  Encoder :

  


  pt_handle->t_x264_param.i_threads = 1;

  


  pt_handle->pt_x264_encoder = x264_encoder_open(&pt_handle->t_x264_param);

  


  Decoder :

  


  pt_handle->pt_avcodec_ctx->thread_count = 23;

  


  i_retval = avcodec_open2(pt_handle->pt_avcodec_ctx, pt_h264_decoder, NULL);

  


  I'm unsure about the cause of this error and how to resolve it. Any insights or suggestions on how to address this issue would be greatly appreciated. Thank you !

  


• avcodec/vvc_mvs : align local motion vector fields

  24 janvier 2024, par James Almer

  avcodec/vvc_mvs : align local motion vector fields
  Should fix "member access within misaligned address 0xf00 for type 'const union
  
  av_alias64', which requires 8 byte alignment" errors as reported by GCC ubsan.
  Signed-off-by : James Almer <jamrial@gmail.com>
  

  • [DH] libavcodec/vvc/vvc_mvs.c

• resending a stream causes ffmpeg to crash

  18 août 2020, par Arikael

  we use ffmpeg 3.4.8 to get udp streams from a source.
  
While the streams may be sent 24/7 or just from time to time, ffmpeg should always listen 24/7.
  
Those streams are out of my control.

  


  The streams which are sent from time to time, are not just paused during the time they are not sent, they are not existing.
  
This means while they are always send with on the same address/port and our application sees them as one stream (or one input in ffmpeg terminology) they are technically multiple separate streams sent to the same address.

  


  The problem is when one of those stream stops, ffmpeg keeps listening for the input (which is good) but it crashes as soon as we send the stream again giving the error :

  


  Application provided invalid, non monotonically increasing dts to muxer in stream 4...   
av_interleaved_write_frame(): invalid argument.


  


  Stream 4 contains synchronous klv metadata.

  


  This is to be expected since the new stream will probably have a lower dts than the old stream.

  


  I cant use the reconnect_* flags since we use an udp source

  


  example
  
ffmpeg -i udp://192.168.2.255:1234 -map 0 -c copy -f mpegts udp://192.168.2.255:1235

  


  log (with loglevel verbose)

  


  [mpegts @ 0x1eb8e60] Timestamps are unset in a packet for stream 3. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[mpegts @ 0x1eb8e60] Application provided invalid, non monotonically increasing dts to muxer in stream 4: 2097600 >= 1732800
av_interleaved_write_frame(): Invalid argument
No more output streams to write to, finishing.
frame=  317 fps= 20 q=-1.0 Lsize=    7252kB time=00:00:23.30 bitrate=2549.1kbits/s speed=1.44x
video:6166kB audio:400kB subtitle:0kB other streams:58kB global headers:0kB muxing overhead: 9.481929%
Input file #0 (udp://192.168.2.255:1234):
  Input stream #0:0 (video): 318 packets read (6334176 bytes);
  Input stream #0:1 (audio): 534 packets read (410112 bytes);
  Input stream #0:2 (data): 0 packets read (0 bytes);
  Input stream #0:3 (data): 56 packets read (9968 bytes);
  Input stream #0:4 (data): 252 packets read (49542 bytes);
  Total: 1160 packets (6803798 bytes) demuxed
Output file #0 (udp://192.168.2.255:1235?broadcast=1):
  Output stream #0:0 (video): 317 packets muxed (6313576 bytes);
  Output stream #0:1 (audio): 534 packets muxed (410112 bytes);
  Output stream #0:2 (data): 0 packets muxed (0 bytes);
  Output stream #0:3 (data): 56 packets muxed (9968 bytes);
  Output stream #0:4 (data): 252 packets muxed (49542 bytes);
  Total: 1159 packets (6783198 bytes) muxed
Conversion failed!


  


  Like mentioned this only happens if the input stream is stopped and started again.

  


  So the question is :
  
Is it somehow possible to give ffmpeg a timeout after which it treats an input as a new stream and/or ignores those dts errors or how can I solve the problem ?

  


  I know I could probably just wait for ffmpeg to fail and then restart it, but maybe there's a cleaner solution.