Recherche avancée

Sur d’autres sites (9626)

• Can't get FFMPEG to convert Samsung Motion Photos from .jpg to .mp4 [closed]

  27 août 2024, par welbeebee

  I pulled a bunch of Samsung Galaxy S21 Ultra motion photos to my PC (Windows 11) for video editing, but they were in .jpg, and for some reason Microsoft Clipchamp couldn't convert them to video. But, I knew the motion photos were intact, bc Microsoft Photos was showing the MOTION option and playing the videos just fine.
So, I'm in FFMPEG just throwing everything at the wall, but can only get still MP4's out of it, with none of the video.

  


  Here's the breakdown of what I'm looking at for :
ffmpeg -i input.jpg

  


  Input #0, image2, from '20240623_233601.jpg':
  Duration: 00:00:00.04, start: 0.000000, bitrate: 874324 kb/s
  Stream #0:0: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/unknown), 2944x2208 [SAR 59:59 DAR 4:3], 25 fps, 25 tbr, 25 tbn


  


  So to get the whole folder converted, I'm trying :
for %i in (*.jpg) do ffmpeg -i "%i" -c:v libx264 -map 0:0 -preset veryslow -crf 18 "%~ni.mp4"

  


  But this just results in a bunch of those still MP4's I mentioned.

  


  I'm assuming the problem starts with that odd duration of 00:00:00.04, with a bitrate of 874324 kb/s, but I'm not sure. I don't understand this mjpeg video format very well at all.

  


  I been trying to work through this with copilot to no success, and so I'm turning to stackoverflow in case anyone can help me out.
Or am I going about this all the wrong way ? Let me know.

  


• How to preserve transparency when using png to make video with ffmpeg

  27 septembre 2016, par Ryan James

  I have a series of png’s that have an alpha channel as a background. Each file is named like file_name.0001.png and so on, in subsequent order. I’d like to join these png’s into a video with ffmpeg and maintain the transparency.

  I’ve tried a couple of things but I suspect I’m running into a codec issue. When I run ffmpeg, the video is created but the background is black.

  If it makes a difference, I’m wanting to use the video in Microsoft Powerpoint. Thanks !

  Edit
  The suggested duplicate is very close to what I was looking for, thank you ! The only reason it’s not a complete solution is none of the options presented in the other thread work well with Microsoft Powerpoint. None of the codecs used in the suggested solution play well with Powerpoint. This is not the fault of ffmpeg, but of Powerpoint.

  Though ffmpeg doesn’t seem to be able to do what I need, I found that imagemagick did the trick. I was able to create a gif from the images and the alpha channel was preserved. I used the following :

  convert -dispose 3 -coalesce images.*.png gif_file_name.gif

  The -dispose 3 is critical as it tells imagemagick to clear the image prior to overlay, otherwise, you can see each image overlaid on each other (since they have the transparent background).

• when ffpmeg drops frames some things aren't played back in real time

  8 février 2024, par Alex028502

  I am trying to run a bunch of ffpmeg processes that act as simulators for cameras, and something funny is happening when I the processor can't keep up with the configured frame rate.

  


  I have replaced the rtsp stream with an output file, and managed to reproduce the issue, so will just show that to keep it simple.

  


  First here is a makefile that creates my source movie :

  


  clock.mp4: Makefile
    rm -f $@
    ffmpeg -f lavfi -i color=c=black:s=4096x2160:r=25 -vf \
"drawtext=fontfile=/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf:fontsize=72:fontcolor=white:x=(w-text_w)/2:y=(h-text_h)/2: \
text='%{eif\:trunc(n/25)\:d}':start_number=0:rate=25" \
-t 60 -r 25 $@


  


  that gives me a one minute long movie that prints the second number to the screen. I have tested it out and the seconds are close enough. I put a lot of pixels to make it easier to jam up my CPU.

  


  Here is the script that creates a processes similar to the one I am trying to debug (called experiment.sh)

  


  I am actually using H.264, but H.265 is easier to overwhelm the processor with

  


  #! /usr/bin/env bash

set -e

echo starting > message$1.txt

rm -f superclock$1.mp4
ffmpeg -re -stream_loop -1 -i clock.mp4 \
       -an -vcodec libx265 -preset ultrafast -sc_threshold -1 -x265-params repeat-headers=1 \
       -vf "drawtext=fontfile=/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf:fontsize=24:fontcolor=white:x=10:y=10:text='%{localtime\:%X}', \
            drawtext=fontfile=/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf:fontsize=24:fontcolor=white:x=10:y=(h-text_h-10):textfile=message$1.txt:reload=1, \
            scale=1920x1080,fps=25" \
       -b:v 3M -minrate 3M -maxrate 3M \
       -bufsize 6M -g 25 superclock$1.mp4 &
pid=$!

for x in $(seq 0 10)
do
    echo $x > message$1.txt
    sleep 10
done

kill -INT $pid || true


  


  It should

  


  

  • put the second in the middle of the screen - 'cause it gets it from the source video

  


  • put the approximate sixth of minute in the lower left corner
(only approximate because of the sleep but close enough)

  


  • put the the wall clock time in the upper left corner

  


  


  and it works

  


  make clock.mpg
./experiment.sh 0
vlc superclock0.mp4


  


  shows something like this


  


  Now here is the interesting part

  


  If I run the script in four different terminals at the same time

  


  ./experiment.sh 1
./experiment.sh 2
./experiment.sh 3
./experiment.sh 4


  


  It can't keep up with the frame rate, and I see this in the output :

  


  frame= 1515 fps= 16 q=0.0 size=     768kB time=00:00:59.96 bitrate= 104.9k


  


  I was hoping the end result would all look ok when I watch it except with fewer frames, but the timestamps of the frames would make it all work as expected

  


  However...

  


  

  • The time in the middle, that is inherited from the source video, the seconds in the middle of the screen, stays in sync with VLC's clock.

  


  • the wall clock in the upper left seems play at 150% speed

  


  • the every ten seconds incrementor in the lower left seems to increment every 7 seconds

  


  • the video is only 1:25 long even though it was recording for at least 1:40 according to sleeps

  


  • the wall clock in the upper right hand corner makes it more than 1'40" and then counter in the lower left makes it to 10.

  


  


  

  


  Here are four states to compare

  


  |                  | Start    | 30" in   | end      |
|------------------+----------+----------|----------|
| Video Time       | 00:00    | 00:30    | 01:24    |
| Wall Clock Time  | 15:05:50 | 15:06:39 | 15:07:39 |
| sixth of minute  | 0        | 4        | 10       |
| seconds counter  | 0        | 30       | 24       |


  


  

  


  So you can see the vlc clock keeps pace with the original clock from the source movie.. even when it is only able to produce frames at 2/3 of the rate. However, the it is taking 50% long to get through the whole source movie I guess ?

  


  I am having trouble coming up with a theory that can explain exactly how this happens.

  


  Does anybody know how I can "correct" this ? (make it so that the movie is played at the same rate that it is recorded)

  


  I am thinking of using a lower frame rate and size as the input video.. but it would be nice to have something that will always work as expected, just with a lower frame rate, no matter how busy the processor is.