Sur d’autres sites (8441)

• Getting ffmpeg error ‘Ignoring unsupported var reason rtmp :// : I/O error’

  6 septembre 2022, par Lectos Lacious

  Same setting worked normally for months, suddenly start to receive ffmpeg errors about ‘unsupported var’ related to rtmp and streaming stop working. Is this error about unavailable server or bad url ? Can someone enlighten me about meaning of unsupported var ?

  


  NOTE : replaced actual url with ‘someurl’

  


  LOG :
Input #0, rtsp, from 'rtsp ://192.168.40.44:554/1' :
  
Metadata :
  
title : 10
  
Duration : N/A, start : 0.000000, bitrate : N/A
  
Stream #0:0 : Video : h264, yuvj420p(pc, bt709), 1280x720, 15 tbr, 90k tbn, 180k tbc
  
Stream #0:1 : Audio : aac, 48000 Hz, stereo, fltp
  
[rtmp @ 0x7f9fdd58c5e0] Ignoring unsupported var reason
  
rtmp ://someurl : I/O error
  
Exiting normally, received signal 2.
  
Input #0, rtsp, from 'rtsp ://192.168.40.44:554/1' :
  
Metadata :
  
title : 10
  
Duration : N/A, start : 0.000000, bitrate : N/A
  
Stream #0:0 : Video : h264, yuvj420p(pc, bt709), 1280x720, 15 fps, 15 tbr, 90k tbn, 180k tbc
  
Stream #0:1 : Audio : aac, 48000 Hz, stereo, fltp
  
[rtmp @ 0x7f62a5869b20] Ignoring unsupported var reason
  
rtmp ://someurl : I/O error
  
Exiting normally, received signal 2.
  
[rtsp @ 0x7f0b4add32a0] max delay reached. need to consume packet
  
[rtsp @ 0x7f0b4add32a0] RTP : missed 2 packets
  
Input #0, rtsp, from 'rtsp ://192.168.40.44:554/1' :
  
Metadata :
  
title : 10
  
Duration : N/A, start : 0.000000, bitrate : N/A
  
Stream #0:0 : Video : h264, yuvj420p(pc, bt709), 1280x720, 15 fps, 15 tbr, 90k tbn, 180k tbc
  
Stream #0:1 : Audio : aac, 48000 Hz, stereo, fltp
  
[rtmp @ 0x7f0b4af13840] Ignoring unsupported var reason
  
rtmp ://someurl : I/O error
  
Exiting normally, received signal 2.
  
Input #0, rtsp, from 'rtsp ://192.168.40.44:554/1' :
  
Metadata :
  
title : 10
  
Duration : N/A, start : 0.000000, bitrate : N/A
  
Stream #0:0 : Video : h264, yuvj420p(pc, bt709), 1280x720, 15 fps, 15 tbr, 90k tbn, 180k tbc
  
Stream #0:1 : Audio : aac, 48000 Hz, stereo, fltp
  
[rtmp @ 0x7fc61ef8b880] Ignoring unsupported var reason

  


• FFmpeg : What re-encoding settings can be used to achieve results similar to Google Drive's video processing ?

  4 août 2023, par Mycroft_47

  Context :

  


  I have a large collection of videos recorded by my phone's camera, which is taking up a significant amount of space. Recently, I noticed that when I uploaded a video to Google Drive and then downloaded it again using IDM (by clicking on the pop-up that IDM displays when it detects something that can be downloaded here's what i mean), the downloaded video retained the same visual quality but occupied much less space. Upon further research, I discovered that Google re-encodes uploaded videos using H.264 video encoding, and I believe I can achieve similar compression using FFmpeg.

  


  Problem :

  


  Despite experimenting with various FFmpeg commands, I haven't been able to replicate Google Drive's compression. Every attempt using -codec:v libx264 option alone resulted in videos larger than the original files.

  


  While adjusting the -crf parameter to a higher value and opting for a faster -preset option did yield smaller file sizes, it unfortunately came at the cost of a noticeable degradation in visual quality and the appearance of some visible artifacts in the video.

  


  Google Drive's processing, on the other hand, strikes a commendable balance, achieving a satisfactory file size without compromising visual clarity, (I should note that upon zooming in on this video, I observed some minor blurring, but it was acceptable to me).

  


  Note :

  


  I'm aware that using the H.265 video encoder instead of H.264 may give better results. However, to ensure fairness and avoid any potential bias, I think the optimal approach is first to find the best command using the H.264 video encoder. Once identified, I can then replace -codec:v libx264 with -codec:v libx265. This approach will ensure that the chosen command is really the best that FFMPEG can achieve, and that it is not solely influenced by the superior performance of H.265 when used from the outset.

  


  Here's the FFMPEG command I am currently using :

  


  ffmpeg -hide_banner -loglevel verbose ^
    -i input.mp4 ^
    -codec:v libx264 ^
    -crf 36 -preset ultrafast ^
    -codec:a libopus -b:a 112k ^
    -movflags use_metadata_tags+faststart -map_metadata 0 ^
    output.mp4


  


  





  


  


  


  


  


  


  


  



  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  Video file	Size (bytes)	Bit rate (bps)	Encoder	FFPROB - JSON
  Original (named 'raw 1.mp4')	31,666,777	10,314,710	!!!	link
  Without crf	36,251,852	11,805,216	Lavf60.3.100	link
  With crf	10,179,113	3,314,772	Lavf60.3.100	link
  Gdrive	6,726,189	2,190,342	Google	link

  


  


  Those files can be found here.

  


  Update :

  


  I continued my experiments with the video "raw_1.mp4" and found some interesting results that resemble those shown in this blog post, (I recommend consulting this answer).

  


  In the following figure, I observed that using the -preset set to veryfast provided the most advantageous results, striking the optimal balance between compression ratio and compression time, (Note that a negative percentage in the compression variable indicates an increase in file size after processing) :


  


  In this figure, I used the H.264 encoder and compared the compression ratio of different outputted files resulting from seven different values of the -crf parameter (CRF values used : 25, 27, 29, 31, 33, 35, 37),


  


  For this figure, I've switched the encoder to H.265 while maintaining the same CRF values used in the previous figure :


  


  Based on these results, the -preset veryfast and a -crf value of 31 are my current preferred settings for FFmpeg, until they are proven to be suboptimal choices.
As a result, the FFmpeg command I'll use is as follows :

  


  ffmpeg -hide_banner -loglevel verbose ^
    -i input.mp4 ^
    -codec:v libx264 ^
    -crf 31 -preset veryfast ^
    -codec:a libopus -b:a 112k ^
    -movflags use_metadata_tags+faststart -map_metadata 0 ^
    output.mp4


  


  Note that these choices are based solely on the compression results obtained so far, and they do not take into account the visual quality of the outputted files.

  


• FFmpeg delay and mix audio streams while keeping overall volume constant

  5 octobre 2020, par unstuck

  I have about 100 audio streams, all with the same intro music/sound, and in some of them the intro is delayed by a few seconds. I want to align and mix all the audio streams such that all the intros play at the same time and the output remains pretty much the same volume throughout. I know in advance how much each stream needs to be delayed by.

  


  Like this in Audacity. Each audio stream is aligned to the intro, and the duration before the intro is arbitrary. (This doesn't solve the volume problem though.)

  


  What I have so far uses adelay and amix. It looks something like this but with more audio streams.

  


  ffmpeg -i 00.oga \
       -i 01.oga \
       -i 02.oga \
       -i 03.oga -filter_complex \
"[0]adelay=delays=     123S:all=1[a0]; \
 [1]adelay=delays=    2718S:all=1[a1]; \
 [2]adelay=delays= 6283185S:all=1[a2]; \
 [3]adelay=delays=11235813S:all=1[a3]; \
 [a0][a1][a2][a3]amix=inputs=4" output.oga


  


  In this example the first stream is delayed by 123 samples, the second by 2 718, the third by 6 283 185, and the by fourth 11 235 813.

  


  This works, except at the beginning of the output it's very quiet. When fed n streams, amix makes each stream 1/nth its original volume, which is a good thing in principle. In this case it's not an entirely good thing, because at the beginning of the output 3 of the 4 audio streams are silent (adelay fills delayed streams with silence), meaning the only audible stream is 1/4 = 25% of its original volume. When the second stream becomes audible, the overall volume is 2/4, with three audible streams 3/4, and with all four streams audible it's 4/4 = 100%.

  


  Instead, I want the the first stream to be at 100% volume when it's the only audible one, 50% volume each when there are two audible streams, etc.

  


  Is there a way to make it so when there are n audio streams but m non-silent audio streams, the volume for each of the audio streams is 1/m not 1/n ? amix does this when streams end ; if one stream ends it changes the volume of the others from 1/n to 1/n-1 over a period of time (dropout_transition : https://ffmpeg.org/ffmpeg-filters.html#amix).

  


  I found a similar question where someone wanted to do something like this but only with 2 audio streams. The answer was to split, trim, and change the volume manually. This would be incredibly complicated with 100 audio streams or more, like in my situation.

  


  Is there any easy way to achieve this, even without FFmpeg ?