Recherche avancée

Sur d’autres sites (3785)

• FFmpeg Dropping Aspect Ratio on FLV Output

  16 septembre 2017, par Mike B

  I am having an issue with FFmpeg dropping the aspect ratio when converting a 1920x1080 stream to a lower resolution (please see below for more information). The objective is to take the output from TVHeadend and convert it to a FLV format that I can stream outside of my house.

  ffmpeg -c:v mpeg2_mmal -i http://192.168.1.142:9981/stream/channelnumber/10.1?profile=pass -c:a libfdk_aac -profile:a aac_he_v2 -b:a 32k -ac 2 -async 48000 -c:v h264_omx -b:v 1800k -sws_flags fast_bilinear -vf scale=720:540 -keyint_min 0 -g 100 -f flv rtmp://192.168.1.110:1935/live/test

  This produces the following onscreen output :

  Output #0, flv, to 'rtmp://192.168.1.110:1935/live/test':
  
    Metadata:
  
      encoder         : Lavf57.82.100
  
      Stream #0:0: Video: h264 (h264_omx) ([7][0][0][0] / 0x0007), yuv420p, 720x540 [SAR 4:3 DAR 16:9], q=2-31, 1800 kb/s, 29.97 fps, 1k tbn, 29.97 tbc
  
      Metadata:
  
        encoder         : Lavc57.105.100 h264_omx
  
      Stream #0:1(eng): Audio: aac (libfdk_aac) (HE-AACv2) ([10][0][0][0] / 0x000A), 48000 Hz, stereo, s16, 32 kb/s
  
      Metadata:
  
        encoder         : Lavc57.105.100 libfdk_aac

  Based on the onscreen output, it appears that that SAR and DAR are correct. It is only when you examine the actual files that the aspect ratio has been dropped.

  Input #0, hls,applehttp, from 'http://192.168.1.110:8080/live/test/index.m3u8':
  
    Duration: N/A, start: 109.116000, bitrate: N/A
  
    Program 0 
  
      Metadata:
  
        variant_bitrate : 0
  
      Stream #0:0: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 720x540, 29.97 tbr, 90k tbn, 180k tbc
  
      Metadata:
  
        variant_bitrate : 0
  
      Stream #0:1: Audio: aac (HE-AACv2) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp
  
      Metadata:
  
        variant_bitrate : 0

  I modified the command to instead save to a local MP4 file :

  ffmpeg -c:v mpeg2_mmal -i http://192.168.1.142:9981/stream/channelnumber/10.1?profile=pass -c:a libfdk_aac -profile:a aac_he_v2 -b:a 32k -ac 2 -async 48000 -c:v h264_omx -b:v 1800k -sws_flags fast_bilinear -vf scale=720:540 -keyint_min 0 -g 100 ~/test.mp4

  And the issue is resolved. I have also tried adding the video filters setsar and setdar to no avail.

  I am performing this on a Raspberry Pi 3, which lacks the ability to de-interlace in hardware. To remedy this, I am simply scaling the video vertically by 1/2. I have tried scaling the output to 960x540 but the Pi has issues keeping up.

• avformat/vobsub : fix several issues.

  29 septembre 2013, par Clément Bœsch

  avformat/vobsub : fix several issues.
  Here is an extract of fate-samples/sub/vobsub.idx, with an additional
  
  text at the end of each line to better identify each bitmap :
      timestamp : 00:04:55:445, filepos : 00001b000 Ace !
  
      timestamp : 00:05:00:049, filepos : 00001b800 Wake up, honey !
  
      timestamp : 00:05:02:018, filepos : 00001c800 I gotta go to work.
  
      timestamp : 00:05:02:035, filepos : 00001d000 < ???>
  
      timestamp : 00:05:04:203, filepos : 00001d800 Look after Clayton, okay ?
  
      timestamp : 00:05:05:947, filepos : 00001e800 I’ll be back tonight.
  
      timestamp : 00:05:07:957, filepos : 00001f800 Bye ! Love you.
  
      timestamp : 00:05:21:295, filepos : 000020800 Hey, Ace ! What’s up ?
  
      timestamp : 00:05:23:356, filepos : 000021800 Hey, how’s it going ?
  
      timestamp : 00:05:24:640, filepos : 000022800 Remember what today is ? The 3rd !
  
      timestamp : 00:05:27:193, filepos : 000023800 Look over there !
  
      timestamp : 00:05:28:369, filepos : 000024800 Where are they going ?
  
      timestamp : 00:05:28:361, filepos : 000025000 < ???>
  
      timestamp : 00:05:29:946, filepos : 000025800 Let’s go see.
  
      timestamp : 00:05:31:230, filepos : 000026000 I can’t, man. I got Clayton.
  Note the two "< ???>" : they are basically split subtitles (with the
  
  previous one), which the dvdsub decoder is now supposed to reconstruct
  
  with a previous commit. But also note that while the first chunk has
  
  increasing timestamps,
      timestamp : 00:05:02:018, filepos : 00001c800
  
      timestamp : 00:05:02:035, filepos : 00001d000
  ...it’s not the case of the second one (and this is not an exception in the
  
  original file) :
      timestamp : 00:05:28:369, filepos : 000024800
  
      timestamp : 00:05:28:361, filepos : 000025000
  For the dvdsub decoder, they need to be "filepos’ed" ordered, but the
  
  FFDemuxSubtitlesQueue is timestamps ordered, which is the reason of the
  
  introduction of a sub sort method in the context, to allow giving
  
  priority to the position, and then the timestamps. With that change, the
  
  dvdsub decoder get fed with ordered packets.
  Now the packet size estimation was also broken : the filepos differences
  
  in the vobsub index defines the full data read between two subtitles
  
  chunks, and it is necessary to take into account what is read by the
  
  mpegps_read_pes_header() function since the length returned by that
  
  function doesn’t count the size of the data it reads. This is fixed with
  
  the introduction of total_read, and old,new_pos. By doing this change,
  
  we can drop the unreliable len16 heuristic and simplify the whole loop.
  
  Note that mpegps_read_pes_header() often read more than one PES packet
  
  (typically in one call it can read 0x1ba and 0x1be chunk along with the
  
  relevant 0x1bd packet), which triggers the "total_read + pkt_size >
  
  psize" check. This is an expected behaviour, which could be avoided by
  
  having a more chunked version of mpegps_read_pes_header().
  The latest change is the extraction of each stream into its own
  
  subtitles queue. If we don’t do this, the maximum size for a subtitle
  
  chunk is broken, and the previous changes can not work. Having each
  
  stream in a different queue requires some little adjustments in the
  
  seek code of the demuxer.
  This commit is only meaningful as a whole change and can not be easily
  
  split. The FATE test changes because it uses the vobsub demuxer.
  

  • [DH] libavformat/mpeg.c
  • [DH] libavformat/subtitles.c
  • [DH] libavformat/subtitles.h
  • [DH] tests/ref/fate/sub2video

• Can any part of an ffmpeg command use expressions ?

  6 avril 2022, par corgrath

  I am still learning how expressions work with ffmpeg, whether any part of a command can be using expression or not.

  


  As an example, I have this command :

  


  ffmpeg -y -i input.mp3 -af "sofalizer=sofa=ClubFritz1.sofa:type=freq:radius=2:speakers='FL 45|FR 45|BL 45|BR 45'" output.mp3

  


  (The file CubFritz1.sofa can by the way be downloaded here)

  


  Which basically applies the sofalizer effect and specify that each channel should be heard / come from, the left side (45 degrees) of the audio.

  


  This works as expected.

  


  However, I cannot seem to get expressions working in the command at all.

  


  For example this :

  


  ffmpeg -y -i input.mp3 -af "sofalizer=sofa=ClubFritz1.sofa:type=freq:radius=2:speakers='FL if(0, 45, 45)'|'FR if(0, 45, 45)'|'BL if(0, 45, 45)'|'BR if(0, 45, 45)'" output.mp3

  


  Which does an if(0, 45, 45) as a test, so regardless the outcome should be 45, right ?

  


  However, when I run this command, it does not seem to work anymore, meaning the sound is not purely coming from the left side.

  


  I have even tried changing the location of the single ' in the command without luck :

  


  ffmpeg -y -i input.mp3 -af "sofalizer=sofa=ClubFritz1.sofa:type=freq:radius=2:speakers=FL 'if(0, 45, 45)'|FR 'if(0, 45, 45)'|BL 'if(0, 45, 45)'|BR 'if(0, 45, 45)'" output.mp3

  


  My question is, what are the rules for getting expressions working in an ffmpeg command ?

  


  How would the command be rewritten so that the if(0, 45, 45) works ?