The default settings for ffmpeg are very low quality, and since you don't specify any codec or quality parameters it's just using the defaults (I don't know why the devs don't fix that because it generates a lot of questions on forums everywhere).
Edit: the defaults are now quite sane. With a recent build of ffmpeg you don't need to specify anything more ...
You can encode to Theora video and Vorbis audio with ffmpeg if it has been compiled with --enable-libtheora and --enable-libvorbis. Depending on your ffmpeg version the default settings may not provide good enough quality. Therefore you must add some additional parameters to enable a constant quality type of mode for the video.
Adjust video ...
Let me explain you from scratch.
MOV, MP4, AVI, MKV etc all these are just containers, It is just kind of wrapper which contains audio, video, text, metadata file together as one file. It does not play a big role in the size of a file.
Size of the file heavily depends on audio and video codec and bit-rate of that audio video codecs.
So there is a ...
ffmpeg has removed their x264 presets so the -vpre setting doesn't work any more.
Now, I have a script for converting video files to a format my Cellphone can handle.
ffmpeg -i input.avi -sws_flags lanczos+accurate_rnd -vf "scale=320:240" -c:v libx264 -crf 20 -preset veryslow -profile:v main -tune fastdecode -c:a copy output.mkv
I'll explain each option
What you are talking about is upscaling and any current HDTV will do upscaling automatically. Upscaling doesn't work miracles though, it will only make it so that the lower quality signal can be watched on a higher quality display. It just multiplies the pixels so that a 720 by 480 (.9 pixel compressed) signal for example doesn't end up only taking up 1/4 ...
Hope this explanation is what you're looking for:
When you transcode to an encoding such as H.264 (MPEG-4 part 10) you necessarily also resample the video, that's part of H.264 compression technique. Nontheless, I doubt if this is the reason you experience a timing gap since the resampling doesn't necessarily influence the clock rate of the media. So, I ...
You may want to use FFMPEG's lut3d filter. It requires you to provide a look-up table (a *.cube file). For example, if you have an ARRI camera you can generate these files using ARRI Color Tool or simply download a package with them from the linked page.
Once you have the files, use FFMPEG like this:
ffmpeg -i "Input.mov" -vf lut3d="ARRIP3D65PQ108-33....
For a server, you definitely want ffmpeg. I would also strongly recommend compiling it yourself (those are Ubuntu instructions, but should work for Debian as well AFAIK) - the best AAC encoder available for ffmpeg (libfdk_aac) cannot be redistributed alongside x264 (because of the GPL), and the version of ffmpeg in the repositories is probably too old for ...
You are using the same bitrate for each video. The bitrate determines how much data is used per second. The resolution has nothing to do with how much data is used, it only impacts the number of points of data which are encoded (and thus determines part of the quality of the video output for a given bitrate).
What you end up with is a lower resolution ...
As you are hardcoding subtitles, the video (with the subtitles added) will be re-encoded.
You can use the CRF rate control method to modulate the quality of the output.
So, start with
ffmpeg -i grdedFinal.mov -vf subtitles=portSbs.srt -crf 18 -c:a copy gradedFinalwithSubs.mov
If the quality's not acceptable, lower that value till it is - in exchange for ...
Generally, H.264 and H.265 (as well as others like VP9) are lossy codecs, at least in their default settings with most encoders. This means that whenever you re-encode from one to another (or even in the same codec), you throw away information.
Whether this information loss is visible or not depends on your source material and the chosen settings, of course....
You can use wonderful ffmpeg for your desired workflow. There is a guide here on this page but once you have the ffmpeg installed, you can simply cd into your folder with sequence, and type in your terminal:
ffmpeg -f image2 -pattern_type glob -i '*.png' -vcodec qtrle -r 25 -s 1920x1080 test.mov
To understand the options, you can check the documentation ...
Devices are often picky, and specifications are usually too uninformative so it's always trial and error. For example, your link indicates that the phone supports MP4 playback, but that is simply a container than can utilize several video and audio formats.
MPEG-4 part 2 video and AAC-LC audio
(partially based on the working video details you provided)
The cabling is likely your problem. The composite cables you're using (red, yellow, white) will only move analog signal from the set top box to the TV. Likewise with RG59 or RG6 (coaxial).
While both varieties of cables there are technically capable of passing digital signals (they don't care... they're just dumb cables), set top boxes typically only ...
If you copied your command there then your issue is probably -acodec:0 mp. That should be -acodec:0 mp3.
You can just use -c:a mp3 to apply the encoding options to all audio tracks at once, no need to apply them for each individually.
Other than that your mapping is correct and shouldn't be the issue.
Edit: To conclude the discussion in the comments ...
One big loss in converting VHS to DVD arises from going through the composite domain. Both VHS and MPEG2 use a separated chroma paradigm -- on the VHS tape are two signals, essentially luma and bandwidth-limited chroma. MPEG2 (the standard for DVD) also uses separate luma and chroma. But the standard output from a VHS player combines the signals in a way ...
Although @stib's advice is sound, I disagree with "to get an appreciable size reduction you would have to throw away a lot of quality". Cameras have to compress on-the-fly, so they use constrained baseline mode, which is to say, they skip most of the tricks that H.264 codec uses to efficiently compress videos. If space isn't a pressing concern, keep them as-...
Update: The VLC TS is malformed.
ffmpeg -i vlc-output.ts -c copy ffmpeg-output.ts
ffmpeg -i ffmpeg-output.ts -c copy working.mp4
The main thing that looks off is the timebase 1000k tbn.
ffmpeg -i vlc-output.ts -c copy -video_track_timescale 90k car-free\ tourism.mp4
The differences between your "works" and "doesn't work" examples are:
and you can set these using ffmpeg:
ffmpeg.exe -i /temp/input.mp4 -c:v mpeg4 -level 3.0 -vtag XVID -s 544x416 -r 25 -qscale 0 /temp/out.avi
Qscale 0 will produce a large file but maintain the best quality.
Please note that changing the ...
Amazingly, the best place to start with a question like this is Youtube. Believe it or not they have help file that explain the process with quite a bit of detail:
On Youtube itself many others have offered up video tutorials on how to do it:
I'm trying to help. First, I don't understand why you're saying FFMPEG H.264 is not the input format?
I don't know the FFMPEG command line well enough (is there anyone who does? ;) ). There's got to be a switch for multipass encoding. I know there are some built-in presets you could probably use and do almost certainly what you're aiming for. These are ...
If you wrote a small script (say in python) you could use the Command line client of the software convert all the videos sequentially. Python has good system calls functionality and make this quite easy.
Wonderful ffmpeg command line utility is the solution. Just check their documentation, but something like the following will probably work for your case:
ffmpeg -i video.mts video%05d.png
This will take your video, and create video00001.png, video00002.png... files in the same folder.
You can find a lot of guides for ffmpeg, or ask here for a specific ...
If you had just 4:3 and 16:9 videos, I would suggest:
ffmpeg -i input.mov -filter:v 'scale=-1:768,crop=1024:ih' \
-c:v libx264 -crf 23 -preset veryfast output.mp4
That would scale a video to a height of 768, scaling the width to keep the aspect ratio; and then it crops the width to 1024, keeping the height at 768. The fact that you are using 1:1 videos as ...
Many different factors can contribute to stutter in video playback. It could be a CPU issue (check your CPU when playing the video) in which case, a simpler codec or a player that can leverage the graphics card for decoding would help. It could also be data rate related though. In this case, using a simpler format would actually compound the problem as ...
The 'interface connector' is (almost certainly) a serial control port, not a video output. LVD stored composite analog video, so there are no chroma or difference signals available to assist in digitizing the video.