when embedding a bigger video in firefox i got audio bugs. It crackles like an old movie.
No problems in Chrome.
The video was converted with VLC to MP4/MOV with H-264 video and MPEG audio codecs.
Because of its a very high quality video, the file size and Bitrates are very high. Is it possible, that firefox has a problem with that?
I know, usually you should never offering a video with that size on a web template, but its local hosted for an kiosk-mode project.
Example File:
FILE
Name: Holliday_Hawaii_2019.mp4
Type: MP4 File
Size: 5.39 GB (5.78.399.926 Bytes)
VIDEO
Resolution: 1920 x 1080 px
Data rate: 8082 kBit/s
Total bitrate: 8721 kBit/s
Frame rate: 23.98 Pictures/Second
AUDIO
Bit rate: 638 kBit/s
Channels: 2
Audio sample: 44.100 kHz
Related
A video file need to be transferred for further video processing. Sharing raw video (y4m) seems impossible. I am having two options
Encoding video file to h264 with crf 0 - lossless - file size is huge.
Encoding video file to h264 with crf 17/18 - virtually lossless - file size is manageable.
After the video is shared, it will be re-encoded only once with crf 22/23 with client info added.
Option 2 seems okay, but the quality should not be degraded on the re-encoding.
Is going with Option 1 and managing huge file is better option than Option 2?
I am new to video encoding and trying to encode a music video for the apple itunes video store.
I am currently using FFmpeg for encoding.
My source file is mp4 file type and file size=650MB
I encode the file using the Apple ProRes 422 (HQ) codec and output a mov file.
ffmpeg -y -i busy1.mp4 -vcodec prores -profile:v 3 -r "29.97" -c:a mp2 busy2.mov
I am trying to encode the video according to the following specs:
● Apple ProRes 422 (HQ)
● VBR expected at ~220 Mbps
Encoded PASP Converted to ProRes From
1920 x 1080 1:1 HDCAM SR, D5, ATSC
1280 x 720 1:1 ATSC progressive
29.97 interlaced frames per second for video sourced
Music Video Audio Source Profile
● MPEG-2 layer II stereo
● 384 kpbs
● 48Khz
The file is encoded perfectly fine however the output is 6Gb in size.
Why would the file be so large after encoding?
Am I doing something wrong here?
The Apple ProRes is not intended for high compression. It is an intermediate codec used in post-production which optimizes the storage as opposed to keeping the videos uncompressed while retaining a high image quality.
You are supposed to use your uncompressed source file as input to retain the maximum quality and not an already lossy-compressed video.
You only mentioned the container format of your input file: MP4 but not the codecs which is the actual important information.
Since the HQ flavor of ProRes uses 220 Mbps the file size can actually increase but you don't gain anything in quality if the source is lossy.
See more here: Apple ProRes
Though you don't gain much by decompressing a source clip thats "Lossy", you do gain in some ways. Compressed video uses a compressed color palette, which can be detrimental when making color corrections or corrections to detail level, especially when you're given interlaced footage to clean up. If you put in the time on detail, microcontrast, and color, you know the benefit of expanded color detail for compressing back down. It also encodes much faster on the back end of your edits. Simply compressing the data down is faster than expanding and then compressing.
However, if you recompress all your video down to the same size and codec as what went in, most encoders and editor apps now test the datarate of the GOP, working on only those GOP's that need to be redone to fit the new settings.
Which bitrates are supported by ffmpeg for AAC-LC encoding?
I want to encode 44.1kHz,16 Bit Mono Audio. The framesize is set to 1024. But only some bitrates seem to be support, if I set the bitrate to 320 it doesn't seem to work properly.
For 44.1 kHz mono with 1024-sample frames, AAC-LC's maximum bitrate is:
(6144 bits/block ÷ 1024 samples/block) × 44100 samples/sec × 1 channel = 264.6 kbit/s
FFmpeg supports 4 different AAC-LC encoders. The best quality can be obtained using libfdk_aac, which supports all the way up to the maximum bitrate.
See also Recommended sampling rate and bitrate combinations.
Since windows 7 build-in mjpeg decoder seems has resolution limitation, it could not decode the mjpeg which has resolution larger than 2592x1944 pixels. So I want to know the ability of windows 8 decoder for mjpeg, could it decode the mjpeg video which resolution larger than 2592x1944 pixels?
I found the build-in decoder could handle the high resolution of 2592x1944 pixels after I trying it on windows 8.
Quick question, i have a movie, which was cut and rendered with Sony Vegas from its original format to a .wmv file. Here comes the tricky part, movie when played, either with VLC or WMP, has a resolution of 656x480 ... BUT when i run a ffmpeg -i on it, it says it has a resolution of 600x480 ....
I took the time of actually capturing a frame and croping it with photoshop and its 656 and not 600 like ffmpeg its reporting, why would this could be happening? How could i fix the headers resolution? Would that have any impact on video re-rendering? As i said, VLC and WMP seems not to care about the incorrect headers and are playing it right, BUT, jwplayer seems to be using the header information, which i don't blame him, its correct to do that, but why the video headers could be wrong?
ffmpeg -i trailer.wmv
Input #0, asf, from 'trailer.wmv':
Duration: 00:01:04.93, start: 3.000000, bitrate: 2144 kb/s
Stream #0.0: Audio: wmav2, 44100 Hz, mono, 32 kb/s
Stream #0.1: Video: wmv3, yuv420p, 600x480 [PAR 59:54 DAR 295:216], 2065 kb/
s, 25.00 tb(r)
And yeah, the PAR/DAR parameters are also wrong, but honestly, i don't understand that technical shit, usually watch video and make sure it look good, any feedback would be appreciated :P
Is there a way to change the container information with ffmpeg so applications that actually do use the container information don't render video incorrectly?
FFMPEG is 100% correct, that technical stuff is important :D
Your PAR (pixel aspect ratio) and DAR (display aspect ratio) are actually correct, and you proved it by capturing a screenshot and measuring.
What threw you off was the PAR. Not all pixels are square! IE: 1:1, although most downloaded videos will be so you probably never noticed. Some players such as VLC will recognize the PAR value and stretch the video accordingly to meet the DAR. DVD video is a great example of this.
See also: http://en.wikipedia.org/wiki/Pixel_aspect_ratio
So ffmpeg says your video width is 600. Multiply that by the PAR and you'll get "real" width. Meaning as if the pixels were square and not rectangular (horizontally).
600 * (59/54) = 656 (rounded) Number look familiar?
Now take the "real" size: 656 / 480 = 1.366 and look at your DAR: 295 / 216 = 1.366
Magic!
As you found out not all video players are smart enough to recognize the PAR and perform the appropriate stretching. You can change it to a 1:1 using ffmpeg easily using the setsar and scale video filters.
ffmpeg ...stuff... -vf "scale=656:480,setsar=1:1" ...more stuff...
For the curious, it's called setsar because it's also refered to as Sample (aka Pixel) Aspect Ratio: http://ffmpeg.org/ffmpeg.html#setsar-1
Hope this help, I'm sure it confuses many people (including myself) at first.