Recherche avancée

Sur d’autres sites (11491)

• Compressing videos from a smartphone

  21 septembre 2019, par fejesjoco

  I have a Nexus 6p with the stock camera. It’s set to record at 1080p, 30fps. Here’s a 5 second sample (11 MB).

  Videos from this phone come out at about 17 Mbps on average. I tried to compress it with ffmpeg with -c:v libx264 -crf 23 -preset veryslow, the result comes out at about 5.5 MB, which is about 9 Mbps.

  I think this bitrate is a bit too much. When I look at torrent file listings, I can see high quality videos at 3 GB in size on average, and if such a movie is 90 minutes long on average, that is about 4-5 Mbps which sounds okay.

  I’m wondering, why the big difference ? I can notice that my video is noisy/grainy (which is expected from a phone), and that might reduce compressibility. I tried a few ffmpeg filters, like hqdn3d and atadenoise, but the noise mostly remained (maybe I didn’t play with it enough). Then I figured, the video is also shaky (which is also expected), and that might reduce compressibility too (and even makes temporal noise filtering less effective). I tried to stabilize it with the deshake filter, but that didn’t help either.

  I know I could just limit the bandwidth to whatever I like, but there must be a reason why ffmpeg thinks it needs a high bandwidth to maintain a certain quality, and a lower bandwidth would just decrease the quality.

  Why do these videos have such a high bitrate ? What’s the best way to compress them more while keeping or even increasing their quality ?

• Compressing videos from a smartphone

  9 novembre 2016, par fejesjoco

  I have a Nexus 6p with the stock camera. It’s set to record at 1080p, 30fps. Here’s a 5 second sample (11 MB).

  Videos from this phone come out at about 17 Mbps on average. I tried to compress it with ffmpeg with -c:v libx264 -crf 23 -preset veryslow, the result comes out at about 5.5 MB, which is about 9 Mbps.

  I think this bitrate is a bit too much. When I look at torrent file listings, I can see high quality videos at 3 GB in size on average, and if such a movie is 90 minutes long on average, that is about 4-5 Mbps which sounds okay.

  I’m wondering, why the big difference ? I can notice that my video is noisy/grainy (which is expected from a phone), and that might reduce compressibility. I tried a few ffmpeg filters, like hqdn3d and atadenoise, but the noise mostly remained (maybe I didn’t play with it enough). Then I figured, the video is also shaky (which is also expected), and that might reduce compressibility too (and even makes temporal noise filtering less effective). I tried to stabilize it with the deshake filter, but that didn’t help either.

  I know I could just limit the bandwidth to whatever I like, but there must be a reason why ffmpeg thinks it needs a high bandwidth to maintain a certain quality, and a lower bandwidth would just decrease the quality.

  Why do these videos have such a high bitrate ? What’s the best way to compress them more while keeping or even increasing their quality ?

• FFmpeg capture, mkvtimestamp_v2 and timecode don't play nice

  24 mai 2021, par Bouke

  Trying to capture and modify the TC in-file afterwards.
I've found a nice way to store the timestamps from the capture.
Gyan's brillant filterchain

  


  This works fine using this line :

  


  ffmpeg -hide_banner -f "decklink" -queue_size "1073741824" -raw_format "auto" -format_code "Hi50" -video_input "sdi" -i "bm mini One" -filter_complex "settb=1/1000,setpts=RTCTIME/1000-1500000000000,mpdecimate,split[out][ts];[out]setpts=N/25/TB[out]" -map "[out]" -c:a "copy" -c:v "prores" -profile:v "1" -vendor "ap10" -pix_fmt "yuv422p10le" "/Volumes/Data/tst1.mov" -map "[ts]" -f mkvtimestamp_v2 "/Volumes/Data/time.txt" -vsync 0


  


  But, when I add -timecode "00:00:00:00" (to force a TC atom in the output), horrible things happen.

  


  ffmpeg -f "decklink" -queue_size "1073741824" -raw_format "auto" -format_code "Hi50" -video_input "sdi" -i "bm mini One" -filter_complex "settb=1/1000,setpts=RTCTIME/1000-1500000000000,mpdecimate,split[out][ts];[out]setpts=N/25/TB[out]" -map "[out]" -timecode "00:01:00:00" -c:a "copy" -c:v "prores" -profile:v "1" -vendor "ap10" -pix_fmt "yuv422p10le" "/Volumes/Data/tst1.mov" -map "[ts]" -f mkvtimestamp_v2 "/Volumes/Data/time.txt" -vsync 0


  


  The timecode does not run at the video speed, skips a frame or two here and there, and the image freezes after a random amount of time (between 10 seconds and a minute or so).

  


  How come the timecode can mess up stuff that much ? From what I understand it's just a couple of atoms in the moov atom, and a reference where the actual TC value (as frames) is stored in the mdat.

  


  I highly suspect the -vsync 0 to also work on the video, and I've had issues with that before. If I omit that, the video is fine, the TC is fine, but there is no metadata output, just the # timecode format v2