Recherche avancée

Sur d’autres sites (6507)

• What happens when I use too much RAM from spawning process with Popen in Python ? [closed]

  2 février 2020, par lms702

  I have a Python script that is rendering a video with FFmpeg where I have all the images and audio I need. I am currently invoking FFmpeg via multiprocessing.Popen, which works very quickly on my computer but the Task Manager shows that I am using 12 GB of RAM while doing so (since there end up being 100s of instances of FFmpeg.exe running). I want to deploy this on a linux server one day with much less RAM, but I worry that I’ll run into problems with my approach. Does Python/the OS handle this or should I limit the number of processes I spawn myself ?

• Preserving original colour spaces with FFmpeg

  12 décembre 2022, par Hashim Aziz

  I'm trying to implement some logic in my FFmpeg scripts to make sure that a video's colourspace is always preserved when upscaling. Just setting the metadata seems to be enough to do this, but the hard part is figuring out which metadata is needed, especially when the colourspace and related colour data reads as unknown, as is so often the case with many of my source videos.

  


  As I understand it, two things determine a video's original colourspace : whether a video is standard or high definition, and if it's standard definition, whether it's NTSC or PAL/SECAM. Based on this, I came up with the following logic to check the height of a video and set colourspace according to it :

  


  height=$(ffprobe -v error -select_streams v:0 -show_entries stream=width -of default=nw=1:nk=1 "$1" | tr -d $'\r')
colour_space=$(ffprobe -v error -select_streams v:0 -show_entries stream=color_space -of default=nw=1:nk=1 "$1" | tr -d $'\r')

# If input is standard definition and colourspace is BT601 (NTSC)
if [[ $height -lt 720 && $colour_space == "smpte170m" ]]; then 
colour_metadata="-colorspace smpte170m -color_trc smpte170m -color_primaries smpte170m" # set metadata to BT601 (NTSC)
# If input is standard definition and colourspace is BT601 (PAL and SECAM) or unknown
elif [[ $height -lt 720 && ($colour_space == "bt470bg" || $colour_space == "unknown") ]]; then 
colour_metadata="-colorspace bt470bg -color_trc gamma28 -color_primaries bt470bg" # set metadata to superior/more common PAL/SECAM
elif [[ $height -ge 720 ]]; then # If input is high definition
colour_metadata="-colorspace bt709 -color_trc bt709 -color_primaries bt709" # set metadata to BT.709
else echo "Unrecognised colorspace $color_space detected, leaving colour untouched"
fi


  


  Is this approach likely to work for the majority of videos ? Is there anything wrong with it that can be improved, or is it completely flawed for some reason that I'm missing ?

  


• What is the technically correct way to achieve A/V sync in an MP4 file ?

  25 juillet 2023, par Douglas B

  I am working with a small header only mp4 library (minimp4) to write mp4 files consisting of AAC audio and HVEC video streams, and using FFmpeg/ffplay/ffprobe to inspect and play them. I am a bit confused however, about mp4 concepts like decode/presentation/composition times and how I should be using those for sync.

  


  Initially, I was writing all samples of audio and video as they came in, and using my expected duration as the duration. This obviously lead to a situation where I sometimes started getting video samples before audio causing the audio to run ahead of video. To correct this, I first attempted to manually set the "timestamp" parameter the library writes as well as use a real calculated duration. I realized this would not work in the mode I was using (non fragmented) and seemed to be an improper approach as the timestamp would be written as a decode timestamp (tfdt, not presentation), so instead I changed my writing functions to throw away any A/V samples that start before the other has some ready. This approach seems to work really well, although I am not sure how resilient it would be to drift over time.

  


  After getting that to work and trying to look through FFmpeg source to see how they are handled, I noticed that ffprobe, at least, does use the decode timestamp as a presentation timestamp in some cases (int64_t pts = pkt->pts != AV_NOPTS_VALUE ? pkt->pts : pkt->dts;). I am also having trouble finding where a valid pkt->pts would come from at this point so it almost seems like the intended case.

  


  Google lead me to the CTTS table/composition timestamp, but that seems to be more for reordering frames (not something I have to worry about as I am using all I-frames for video) so I am a bit at a loss/confused about what the technically proper, or at least most common/supported way of handling A/V sync in MP4 files is.