Recherche avancée

Sur d’autres sites (4292)

• FFmpeg : MD5 hash of M3U8 playlists generated from same input video with different segment durations (after applying video filter) don't match

  30 juillet 2020, par Saurabh P Bhandari

  Here are a few commands I am using to convert and transize a video in MP4 format to a M3U8 playlist.

  


  For a given input video (MP4 format), generate multiple video segments with segment duration 30 seconds.

  


  ffmpeg -loglevel error -i input.mp4 -dn -sn -an -c:v copy -bsf:v h264_mp4toannexb -copyts -start_at_zero -f segment -segment_time 30 30%03d.mp4 -dn -sn -vn -c:a copy audio.aac


  


  Apply a video filter (in this case scaling) on each segment and convert it to a M3U8 format.

  


  ls 30*.mp4 | parallel 'ffmpeg -loglevel error -i {} -vf scale=-2:144 -hls_list_size 0 {}.m3u8'


  


  Store the list of m3u8 files generated in list.txt in this format file 'segment-name.m3u8'

  


  for f in 30*.m3u8; do echo "file '$f'" >> list.txt; done


  


  Using concat demuxer, combine all segment files (which are in M3U8 format) and the audio to get one final m3u8 playlist pointing to segments with duration of 10 seconds.

  


  ffmpeg -loglevel error -f concat -i list.txt -i audio.aac -c copy -hls_list_size 0 -hls_time 10 output_30.m3u8


  


  ---

  


  I can change the segment duration in the first step from 30 seconds to 60 seconds, and compare the MD5 hash of the final M3U8 playlist generated in both the cases using this command :

  


  ffmpeg -loglevel error -i <input m3u8="m3u8" playlist="playlist" /> -f md5 -&#xA;

  


  The MD5 hash of the output files differ, i.e., video streams of output_30.m3u8 and output_60.m3u8 are not the same.

  


  Can anyone elaborate on this ?

  


  (I expected the MD5 hash to be the same)

  


• FFmpeg audio formats : ipod vs mov (for ALAC)

  22 juillet 2022, par Fabien Snauwaert

  In converting to Apple Lossless (ALAC) using FFmpeg, I have two options :

  


  ffmpeg -y -i whatever.wav -b:a 256k -ar 16000 -ac 1 -f ipod -acodec:a alac whatever.ipod.m4a
# Output #0, ipod, to 'content/tests/comparing-codecs/whatever.ipod.m4a':

ffmpeg -y -i whatever.wav -b:a 256k -ar 16000 -ac 1 -f mov -acodec:a alac whatever.mov.m4a
# Output #0, mov, to 'content/tests/comparing-codecs/whatever.mov.m4a':


  


  (I could also leave the -f alone, which the defaults to ipod.)

  


  This results in near identical files, from ffprobe :

  


  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'content/tests/comparing-codecs/whatever.ipod.m4a':
  Metadata:
    major_brand     : M4A
    minor_version   : 512
    compatible_brands: isomiso2
    encoder         : Lavf58.29.100
  Duration: 00:00:01.46, start: 0.000000, bitrate: 67 kb/s
    Stream #0:0(und): Audio: alac (alac / 0x63616C61), 16000 Hz, mono, s16p, 63 kb/s (default)
    Metadata:
      handler_name    : SoundHandler


  


  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'content/tests/comparing-codecs/whatever.mov.m4a':
  Metadata:
    major_brand     : qt
    minor_version   : 512
    compatible_brands: qt
    encoder         : Lavf58.29.100
  Duration: 00:00:01.46, start: 0.000000, bitrate: 67 kb/s
    Stream #0:0: Audio: alac (alac / 0x63616C61), 16000 Hz, mono, s16p, 63 kb/s (default)
    Metadata:
      handler_name    : SoundHandler


  


  Only the file size is slightly different, with the ipod file 43 bytes smaller.

  


  I'm able to play both files in on macOS and iPhone, at least on the devices I had access to.

  


  My question is : is there any practical difference between formats ? Is a given format preferable for a specific use ?

  


• How does mp4 block matching work

  19 juin 2019, par YAHsaves

  I’ve been working on a video encoder that uses block matching to find similar blocks on previous frames.

  For the sake of simplicity I’ll leave out most of the details, but I’m wondering if I got the block matching algorithm right.

  In order to find a block on a previous frame my encoder uses the mean squared algorithm for the Y channel in YUV color space.

  This works by comparing each pixel of the block we want to match, with the block on the previous frame. It takes the difference of each pixel and squares it.

  After all the pixels are compared the block that has the least average difference is chosen as the desired block.

  Now this is where I need help. My encoder looks at every possible block in a 256x256 area and uses half pixel searches as well. The smallest block size it can use is 4x4.

  From what I’ve read online this is the same things mp4 uses.

  However I can’t find nearly as many blocks as mp4 appears to be able to find.

  For example here are 2 frames I want to compress. The first will be the I frame and the second is the P frame :

  

  Now after my encoder has run it is able to reduce the second frame by 80% and, what it can’t match close enough it saves as "difference" blocks. Which are grey blocks only recording the difference. They look like this :

  

  Now what I don’t get is to save these "difference" blocks as a jpg takes roughly 90kb to be accurate enough.

  Multiply that by 24 (24 frames per second) you get 2070kb per second. That’s not including how much space the actual motion vectors take up or anything else.

  However somehow mp4 is able to compress the video of the images above into a mere 700kb per second and still look better than my encoder at much larger data amounts.

  Why is this ? Is there something I’m doing wrong when looking for blocks ? Any help would be much appreciated.