Recherche avancée

Sur d’autres sites (5279)

• ffprobe to bitrate variable stopped working

  6 novembre 2023, par Bricktop

  I have a simple script to encode a video using the same bitrate as the original. I use ffprobe to fetch the bitrate like this :

  


  ffprobe "%file%" -v 0 -select_streams v:0 -show_entries stream=bit_rate -print_format compact=p=0:nokey=1 >%temp%\bitrate.txt


  


  However, while fixing a but in the script where I had an odd number of " marks, I suddenly ran into this problem with ffprobe :

  


  Argument ' -v 0 -select_streams v:0 -show_entries stream=bit_rate -print_format compact=p=0:nokey=1 >C:\Users\ADMINI~1\AppData\Local\Temp\bitrate.txt' provided as input filename, but 'D:\VIDEO\AMBIANCE\SCOPITONE\MUSIC TELEVISION\This Here - Calm - OFFICIAL VIDEO (1080p 25fps AV1-128kbit AAC).mp4' was already specified.


  


  I am trying to understand this, scanning insanely for yet another " or something in my code but can't figure it out. Here is the full code :

  


  :: write file to queue (first)
move /y "%~dpn0.txt" "%temp%\%~n0.tmp" >nul
echo "%~1" >"%~dpn0.txt"
type "%temp%\%~n0.tmp" >>"%~dpn0.txt"

:: desyncronize instances (todo: try support for adding 9 files at a time)
timeout /t %time:~9,1% /nobreak
:: if not first instance exit
tasklist /fi "imagename eq handbrakecli.exe" | find /i "handbrakecli" && exit
title Transcode

:: delegate queue
for /f "delims=" %%f in (%~dpn0.txt) do (
    set "name=%%~nf"
    set "file=%%~f"
    rem todo: if file has x264 or other video codec mentioned, change to x265
    set "code=%%~dpnf (x265 transcoded)%%~xf"
    call :transcode
)
echo all done!
exit /b

:transcode
title "%name%"
if not exist "%file%" echo %date% %time% source file missing %file% >>%~dpn0.log & goto cleanup
if exist "%code%" echo %date% %time% target file exists %file% >>%~dpn0.log & goto cleanup

:: determine appropriate bitrate (does not seem to work on .webm files, closing the script as a result)
%~dp0ffprobe "%file%" -v 0 -select_streams v:0 -show_entries stream=bit_rate -print_format compact=p=0:nokey=1 >%temp%\bitrate.txt
set /p bitrate=<%temp%\bitrate.txt
:: reduce to full kilobytes
set "bitrate=%bitrate:~0,-3%"
if not defined bitrate echo failed to fetch bitrate & echo %date% %time% no bitrate for %file% >>%~dpn0.log & exit /b
if %bitrate% gtr 7000 set bitrate=7000

:: transcode
%~dp0HandBrakeCLI -i "%file%" -o "%code%" --encoder x265_10bit --encoder-preset slow --encoder-profile main444-10 --vb %bitrate% --two-pass --turbo --audio 1-9 --aencoder copy --audio-copy-mask aac,ac3,mp2,mp3,opus --audio-fallback opus --ab 160 --drc 2.0

:: remove current file from queue, regardless
:cleanup
findstr /v /c:"%file%" "%~dpn0.txt" >"%temp%\%~n0.tmp"
move /y "%temp%\%~n0.tmp" "%~dpn0.txt"


  


  It appears that the set "file=%%~f" is the problem, somehow it shows up as set "file=D:\VIDEO\this video here.mp4" " where the last two characters " should not belong, and I don't know what to change to fix this.

  


  Every type of improvement to the script is very welcomed !

  


• Why iFrame is a good idea

  15 octobre 2009

  I’ve seen some hilariously uninformed posts about the new Apple iFrame specification. Let me take a minute to explain what it actually is.

  First off, as opposed to what the fellow in the Washington Post writes, it’s not really a new format. iFrame is just a way of using formats that we’ve already know and love. As the name suggests, iFrame is just an i-frame only H.264 specification, using AAC audio. An intraframe version of H.264 eh ? Sounds a lot like AVC-Intra, right ? Exactly. And for exactly the same reasons - edit-ability. Whereas AVC-Intra targets the high end, iFrame targets the low end.

  Even when used in intraframe mode, H.264 has some huge advantage over the older intraframe codecs like DV or DVCProHD. For example, significantly better entropy coding, adaptive quantization, and potentially variable bitrates. There are many others. Essentially, it’s what happens when you take DV and spend another 10 years working on making it better. That’s why Panasonic’s AVC-Intra cameras can do DVCProHD quality video at half (or less) the bitrate.

  Why does iFrame matter for editing ? Anyone who’s tried to edit video from one of the modern H.264 cameras without first transcoding to an intraframe format has experienced the huge CPU demands and sluggish performance. Behind the scenes it’s even worse. Because interframe H.264 can have very long GOPs, displaying any single frame can rely on dozens or even hundreds of other frames. Because of the complexity of H.264, building these frames is very high-cost. And it’s a variable cost. Decoding the first frame in a GOP is relatively trivial, while decoding the middle B-frame can be hugely expensive.

  Programs like iMovie mask that from the user in some cases, but at the expensive of high overhead. But, anyone who’s imported AVC-HD video into Final Cut Pro or iMovie knows that there’s a long "importing" step - behind the scenes, the applications are transcoding your video into an intraframe format, like Apple Intermediate or ProRes. It sort of defeats one of the main purposes of a file-based workflow.

  You’ve also probably noticed the amount of time it takes to export a video in an interframe format. Anyone who’s edited HDV in Final Cut Pro has experienced this. With DV, doing an "export to quicktime" is simply a matter of Final Cut Pro rewriting all of the data to disk - it’s essentially a file copy. With HDV, Final Cut Pro has to do a complete reencode of the whole timeline, to fit everything into the new GOP structure. Not only is this time consuming, but it’s essentially a generation loss.

  iFrame solves these issues by giving you an intraframe codec, with modern efficiency, which can be decoded by any of the H.264 decoders that we already know and love.

  Having this as an optional setting on cameras is a huge step forward for folks interested in editing video. Hopefully some of the manufacturers of AVC-HD cameras will adopt this format as well. I’ll gladly trade a little resolution for instant edit-ability.

• ffmpeg how to set max_num_reorder_frames H264

  13 juin, par Vasil Yordanov

  Anyone know how can I set max_num_reorder_frames to 0 when I am encoding H264 video ?
You can find in the docs as uint8_t H264RawVUI::bitstream_restriction_flag

  


  PS. Based on the discussion in the comments. What I actually want to accomplish is to have all the frames written in the order in which they were encoded. My use-case is - I have 1000 images for example. I encode each one of them using the codec, but then when I investigate a little bit and check the actual packets in the H264 container, I see that I have cases when one frame is written twice (for example ... 1,2,3,3,4,5,6,7,7 ...) what I want is once I decode the the H264 container I want to get the same images which I encoded. Is that possible and how ?

  


  P.P.S : I don't think the g=1 works - giving some more code for reference. This is what I currently have :

  


  import numpy as np
import ffmpeg, subprocess, av

width, height, encoding_profile, pixel_format = 1280, 800, 'main', 'yuv420p'

# here I create 256 frames where each one has unique pixels all zeros, ones, twos and etc.
np_images = []
for i in range(256):
    np_image = i + np.zeros((height, width, 3), dtype=np.uint8)
    np_images.append(np_image)

print(f'number of numpy images: {len(np_images)}')

encoder = (ffmpeg
    .input('pipe:', format='rawvideo', pix_fmt='rgb24', s='{}x{}'.format(width, height))
    .output('pipe:', format='H264', pix_fmt=pixel_format, vcodec='libx264', profile='main', g=1)
    .run_async(pipe_stdin=True, pipe_stdout=True)
)

for timestamp, frame in enumerate(np_images):
    encoder.stdin.write(
        frame
        .astype(np.uint8)
        .tobytes()
    )

encoder.stdin.close()
output = encoder.stdout.read()
encoder.stdout.close()

# here I decode the encoded frames using PyAV
frame_decoder = av.CodecContext.create("h264", "r")
frame_decoder.thread_count = 0
frame_decoder.thread_type = 'NONE'
packets = frame_decoder.parse(output)
decoded_frames = []

for packet in packets:
    frame = frame_decoder.decode(packet)
    decoded_frames.extend(frame)

decoded_frames.extend(frame_decoder.decode())
print(f'number of decoded frames: {len(decoded_frames)}')
print('keyframe boolean mask')
print([e.key_frame for e in decoded_frames])

decoded_np_images = []

for frame in decoded_frames:
    decoded_np_images.append(np.array(frame.to_image()))

print(f'number of decoded numpy images: {len(decoded_np_images)}')

# here I check what the decoded frames contain (all zeros, ones, twos and etc.)
print([e[0,0,0].item() for e in decoded_np_images])


  


  the particular problem which I am facing is that in the output you can observe this :

  


  


  number of decoded numpy images : 255

  


  [0, 1, 2, 3, 3, 4, 5, 6, 8, 9, 10,
10, 11, 12, 13, 15, 16, 17, 17, 18, 19, 20, 22, 23, 24, 24, 25, 26,
27, 29, 30, 31, 31, 32, 33, 34, 36, 37, 38, 39, 39, 40, 41, 43, 44,
45, 46, 46, 47, 48, 50, 51, 52, 53, 53, 54, 55, 57, 58, 59, 60, 60,
61, 62, 64, 65, 66, 67, 67, 68, 69, 71, 72, 73, 74, 74, 75, 76, 78,
79, 80, 81, 81, 82, 83, 85, 86, 87, 88, 88, 89, 90, 91, 93, 94, 95,
95, 96, 97, 98, 100, 101, 102, 102, 103, 104, 105, 107, 108, 109, 109,
110, 111, 112, 114, 115, 116, 116, 117, 118, 119, 121, 122, 123, 123,
124, 125, 126, 128, 129, 130, 131, 131, 132, 133, 135, 136, 137, 138,
138, 139, 140, 142, 143, 144, 145, 145, 146, 147, 149, 150, 151, 152,
152, 153, 154, 156, 157, 158, 159, 159, 160, 161, 163, 164, 165, 166,
166, 167, 168, 170, 171, 172, 173, 173, 174, 175, 176, 178, 179, 180,
180, 181, 182, 183, 185, 186, 187, 187, 188, 189, 190, 192, 193, 194,
194, 195, 196, 197, 199, 200, 201, 201, 202, 203, 204, 206, 207, 208,
208, 209, 210, 211, 213, 214, 215, 216, 216, 217, 218, 220, 221, 222,
223, 223, 224, 225, 227, 228, 229, 230, 230, 231, 232, 234, 235, 236,
237, 237, 238, 239, 241, 242, 243, 244, 244, 245, 246, 248, 249, 250,
251, 251, 252, 253]

  


  


  I still have frames which are appearing twice (and respectively some are missing)