This allows you to loop an input without needing to re-encode.
Make a text file. Contents of an example text file to repeat 4 times.
Then run ffmpeg:
ffmpeg -f concat -i list.txt -c copy output.mp4
For Linux users
This example is the same as above but you don't have to ...
If parts of the file reside on physically bad sectors, or for whatever reason, the OS cannot serve the whole file to FFmpeg, then naturally FFmpeg can't do anything about that. You should get a utility which can ignore those portions and write the salvageable parts to a new file, like ddrescue.
Now, if the file protocol is not the cause of errors, you can ...
With ffmpeg 2.8.4, the following command creates output.mp4 that is a repeating copy of input.mp4 until the ffmpeg process is stopped:
ffmpeg -stream_loop -1 -i input.mp4 -c copy output.mp4
This command won't terminate on its own, and the output file will grow infinitely.
IANAL, but as far as I understand it, if you're charging viewers for h.264 / MPEG-4 AVC content you do need to pay license fees. Even though x264 / ffmpeg are Free with a big F, they are just software libraries for encoding video streams into the H.264/MPEG-4 AVC format, which is covered by the MPEG patent. But the threshold for when fees are applicable is ...
At least on FFmpeg 2.8.x (but oldie should works too) you can use lavfi as input format and complex filter graph using movie and setpts filters as a argument for -i option.
Next command doing this work for you:
ffmpeg -re -f lavfi -i "movie=filename=input.mp4:loop=0, setpts=N/(FRAME_RATE*TB)" output.mp4
Zero loop= arguments means infinity loop. Values ...
tl;dr: Since Youtube reencodes all videos regardless of the upload format, it really isn't that important. Just export your video with a high bitrate to preserve quality. Also see my answer here regarding quality loss caused by Youtube.
Long answer: Each reencoding of a video to a compressed format lowers the quality. Usually, that means you'll lose quality ...
x264 supports both 8-bit and 10-bit outputs, and you don't have to do anything special.
If using ffmpeg you can see what pixel formats and bit depths are supported by libx264:
$ ffmpeg -h encoder=libx264
Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p nv12 nv16 nv21 yuv420p10le yuv422p10le yuv444p10le nv20le
PAL and NTSC have different color primaries, so
NTSC = SMPTE 170M = BT 601 525
PAL = BT 470 BG = BT 601 625
See the rows for value 5 & 6 on the table on page 387 of the active H.264 standard.
So the right args for ffmpeg are:
ffmpeg -i input \
-colorspace smpte170m -color_primaries smpte170m -color_trc smpte170m
Edit: I should probably remove some of the worrying conclusions about using x264 / ffmpeg that I now believe are unfounded. I put a section at the end to clear it up. For now I'm going to leave the whole mess here. Don't panic, x264 and ffh264 appear to be fine, legally, even for producing commercial videos at the standard royalty rates.
Just to clear up ...
Seeing that in the text of your question you have started discussing other utilities, i will assume that you are not interested in sticking with ffmpeg, but rather in getting the job done.
In my experience with libav and MTS i have had no problems with the framerate, the files get remuxed perfectly.
I have just attempted the following with one of my files:
YouTube will re-encode whatever you give it. VP9 is currently too slow to encode. So the best choice is to either:
Give it the original footage, or if it is not accepted by YouTube or is too big to upload, then...
Re-encode to H.264
ffmpeg will accept just about any input and will provide a great quality output. Development is very active, so it is ...
One of the bits of information associated with a H264 stream is its level. The level informs the decoder the computational resources needed for a successful decode. Turns out that the highest level 5.2 supports upto 9437184 luma samples per frame, which is the number of luma samples needed for a frame of size 4096x2304. So, there may be encoders that can (be ...
The CRF scales for x264 and x265 do not correspond. x265 CRF 28 is supposed to be equivalent to x264 CRF 23. But x265 is not yet as mature in its development as x264, so take that CRF equivalence with a pinch of salt.
That said, you can try to establish your own calibration between the current versions of the encoding libraries in your ffmpeg by running ...
It's an artifact of the player, not the encoder.
I used the command below to generate a RGB format capture in HuffYUV
ffmpeg -f dshow -video_size 1920x1080 -framerate 30 -i video="screen-capture-recorder" -c:v huffyuv -t 5 cap.mkv
Then transcoded the file to
x264 lossless RGB
ffmpeg -i cap.mkv -c:v libx264rgb -crf 0 -preset ultrafast h264rgb.mkv
Well going by the numbers h264 has a lesser bit-depth and color accuracy than ProRes 422. PR422 has 10bit and 4:2:2 chroma sub-sampling, h264 has 8bit and 4:2:0 unless you encode in the Hi422P Intra profile which isn't very well supported in the wild but offers 10bit and 4:2:2.
So in that case I don't think you will have any difference what so ever between ...
edit: I successfully made a 10bit encode of Ducks Take Off.
First way: I built a 10bit x264 binary that statically links libx264.
cp -al x264-git x264-10bit # instead of changing my normal git checkout
./configure --extra-cflags=-march=native --enable-static --disable-interlaced --bit-depth=10
sudo install x264 /usr/local/bin/x264-...
H.264/AVC is not limited for 4K in terms of max resolution as it supports DCI 4K (4092x2160) @ 60 fps at Level 5.2. For example Sony already uses XAVC which is exactly 4K AVC.
For a while the max level was 5.1 and 5.2 was introduced later. If needed new levels can be introduced as long there's the hardware to support it.
For eg. the Nvidia NVEC supports ...
ffmpeg -i input -c:v libx264 -intra output
For H265, seems no alias or preset has been set yet
ffmpeg -i input -c:v libx265 -x265-params frame-threads=4:keyint=1:ref=1:no-open-gop=1:weightp=0:weightb=0:cutree=0:rc-lookahead=0:bframes=0:scenecut=0:b-adapt=0:repeat-headers=1 output
H265 code stolenborrowed from here.
Technically lossless, or real lossless, means that when the output is decoded by a conformant decoder, the result is mathematically identical to the input.
Visually lossless is a non-rigorous term that indicates subjective transparency i.e. output which to the lay human eye looks indistinguishable from the original. The output may look different if a viewer ...
You are correct: h.264 is non-free and content producers as well as developers are obliged to pay royalties to MPEGLA for its use - but only if they are charging for their content, and the volume goes over the threshold MPEGLA sets (which is in the order of 100,000 paying subscribers or > 12 minutes in length if charging title-by-title). Thjey have also said ...
Use it. Nothing else can provide the the same quality per bitrate as x264 (the top-class H.264 encoder) while not taking 10,000 years to encode (x265 'n VP9).
Use a recent ffmpeg build since development is so active. Static builds are available and easy.
Add -movflags +faststart to your command. Once encoding is finished this option will ...
Has anyone done or seen any tests comparing Apple ProRes 422 with high-bitrate H.264?
No, but I can tell you that x264 can get as close to lossless as you want (or even mathematically lossless, with -qp 0). x264 can produce h.264 streams in 4:2:0, 4:2:2, or 4:4:4 YUV colorspaces, at 8 or 10 bits per component. (It can also do RGB, but unless you're doing ...
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 per this ffmpeg bug
Interlaced H.264 packets are split causing MP4 STTS
when remuxing a mpeg-ts containing interlaced H.264 into mp4, both
fields of each video frame are split into seperate packets. Software
such as Mediainfo uses the STTS to determine the frame rate. It will
show as 50fps instead of 25fps
The frame rate mismatch reported here ...
You might want to try to enforce the original frame rate by using -r 29.97. FFmpeg is probably trying to adjust the framerate for some reason.
Your syntax is otherwise correct and shouldn't produce that error.
Regarding your third question. Simply not possible.
You can omit frames when using codecs that encode frames individually but thats not the case with ...
All anyone might be able to say is that there are no known holes in the various players. (I don't know if that's true, just that it's impossible to know that there are no undiscovered bugs in a complex piece of code.) H.264 streams are complex enough to have lots of corner cases. They're parsed with speed-optimized code written in C and assembly.
I would get as far away from EE as possible. Using the x264 tool, and mp4box, you can convert and segment out the files which are ready to be streamed to any dash compatible players. Especially since you mentioned using batch scripts, this is a great solution I think.
This is a good guide: http://www.dash-player.com/blog/2014/11/mpeg-dash-content-generation-...