> Clay via ffmpeg-user (12022-11-02):
>> Doesn't this serial ordering of the same command (-c:v ) twice just
>> drive cpu workload up for no actual benefit?
>>
>> To clarify: executing -c:v and then executing -c:v just
>> causes one output: . Thus you are forcing the CPU to
Clay via ffmpeg-user (12022-11-02):
> Doesn't this serial ordering of the same command (-c:v ) twice just
> drive cpu workload up for no actual benefit?
>
> To clarify: executing -c:v and then executing -c:v just
> causes one output: . Thus you are forcing the CPU to
>
> Le 31/10/2022 à 14:23, Naveen.B a écrit :
>> I observed some weird behaviour with fast and medium preset,
>>
>> fast preset:
>> *ffmpeg -pixel_format gray10le -s 1600x1300 -r 30 -i
>> CapturedImage-%03d.raw
>> -c:v rawvideo -pixel_format yuv420p -f rawvideo -c:v libx264 -preset
>> fast
>> -crf
Say I have an input file with several subtitles, one of them being
flagged "default" (say the 0:s:1 stream, that is the 2nd subtitle
stream). I am copying all of them: "-map 0:s -c:s copy"
Empirically I have found that:
* no option
-> the default flag is unmodified
* "-disposition:s:2
Le 01/11/2022 à 00:01, Carl Zwanzig a écrit :
-c:v rawvideo -pixel_format yuv420p
Use the video codec "rawvideo" with that pixel format for output, except
AFAICT that there is no video encoder "rawvideo" (that should throw an
error, which because of the missing command output, we don't see).
Le 31/10/2022 à 14:23, Naveen.B a écrit :
I observed some weird behaviour with fast and medium preset,
fast preset:
*ffmpeg -pixel_format gray10le -s 1600x1300 -r 30 -i CapturedImage-%03d.raw
-c:v rawvideo -pixel_format yuv420p -f rawvideo -c:v libx264 -preset fast
-crf 18 test.raw*
"-c:v
