Am Di., 25. Juni 2019 um 20:32 Uhr schrieb Ulf Zibis :
>
> Am 25.06.19 um 20:16 schrieb Carl Eugen Hoyos:
> > Am Di., 25. Juni 2019 um 20:11 Uhr schrieb Ulf Zibis :
> >> Am 25.06.19 um 15:04 schrieb Carl Eugen Hoyos:
> >>> Am Di., 25. Juni 2019 um 14:15 Uhr schrieb Ulf Zibis :
> >>>
> my
Am Di., 25. Juni 2019 um 22:00 Uhr schrieb Le Chiffre
:
>
> I have found that the psnr result from the psnr filter, vs the psnr that is
> part of libvmaf (calling it via ffmpeg), differs slightly, generally under
> 1%. I suppose the implementation is different.
>
> This seems ok. What is more
Am Mi., 26. Juni 2019 um 00:11 Uhr schrieb Peter B. :
> Is it possible somehow to transcode any source audio format type to its
> raw, uncompressed format that matches the source?
>
> I'm dealing with collections of mixed input format combinations, and am
> trying to find a way to bash-automate
On 6/25/19 6:11 PM, Peter B. wrote:
Hi everyone :)
Is it possible somehow to transcode any source audio format type to its
raw, uncompressed format that matches the source?
I'm dealing with collections of mixed input format combinations, and am
trying to find a way to bash-automate something.
Hi everyone :)
Is it possible somehow to transcode any source audio format type to its
raw, uncompressed format that matches the source?
I'm dealing with collections of mixed input format combinations, and am
trying to find a way to bash-automate something.
For video "-f rawvideo" seems to do
I have found that the psnr result from the psnr filter, vs the psnr that is
part of libvmaf (calling it via ffmpeg), differs slightly, generally under
1%. I suppose the implementation is different.
This seems ok. What is more interesting is that libvmaf-psnr clearly has a
range up to 60 whereas
Am 25.06.19 um 20:18 schrieb Carl Eugen Hoyos:
> Am Di., 25. Juni 2019 um 20:07 Uhr schrieb Ulf Zibis :
>
>> Question 4.) So why is the default of the dev build set to such bad
>> quality and why are the q factors such incoherent?
> It is not "set to such bad quality" but your command line didn't
Am 25.06.19 um 20:16 schrieb Carl Eugen Hoyos:
> Am Di., 25. Juni 2019 um 20:11 Uhr schrieb Ulf Zibis :
>> Am 25.06.19 um 15:04 schrieb Carl Eugen Hoyos:
>>> Am Di., 25. Juni 2019 um 14:15 Uhr schrieb Ulf Zibis :
>>>
my input is a 1.5 minute mp4 video with 19.5 MB
When I use (with
Am Di., 25. Juni 2019 um 20:07 Uhr schrieb Ulf Zibis :
> Question 4.) So why is the default of the dev build set to such bad
> quality and why are the q factors such incoherent?
It is not "set to such bad quality" but your command line didn't make
sense.
Carl Eugen
Am Di., 25. Juni 2019 um 20:11 Uhr schrieb Ulf Zibis :
>
> Am 25.06.19 um 15:04 schrieb Carl Eugen Hoyos:
> > Am Di., 25. Juni 2019 um 14:15 Uhr schrieb Ulf Zibis :
> >
> >> my input is a 1.5 minute mp4 video with 19.5 MB
> >>
> >> When I use (with build from dev):
> >> ./ffmpeg in.mp4 -c:a
Am 25.06.19 um 15:04 schrieb Carl Eugen Hoyos:
> Am Di., 25. Juni 2019 um 14:15 Uhr schrieb Ulf Zibis :
>
>> my input is a 1.5 minute mp4 video with 19.5 MB
>>
>> When I use (with build from dev):
>> ./ffmpeg in.mp4 -c:a copy out.mp4
> You do not specify an encoder here, mp4 defaults to x264.
Am 25.06.19 um 15:23 schrieb Moritz Barsnick:
> The reason for the size difference is pretty obvious, if you actually
Not to me. With setting q the same value for both builds, i.e. 28.0, the
size and the visual quality is *much different*, even from honoring the
complete output and even libx264
Hello all,
Can someone tells me what element (array or single parameter) can give me
the prediction error associated to a motion vector during motion estimation
process in ffmpeg?
I see many elements like penalty_factor, score_map, current_mv_penalty,
mv_penalty. But I don't know which one can
On 25-06-2019 06:34 PM, Carl Eugen Hoyos wrote:
qmax integer (encoding,video)
Set max video quantizer scale (VBR). Must be included
between -1 and 1024, default value is 31.
This option only applies to (some) internal encoders, not x264.
The libx264 wrapper does look at and
On Tue, Jun 25, 2019 at 14:48:58 +0200, Ulf Zibis wrote:
> > my input is a 1.5 minute mp4 video with 19.5 MB
[...]
> > ./ffmpeg in.mp4 -c:a copy out.mp4
> > ffmpeg version N-93873-g6276b4db97 Copyright (c) 2000-2019 the
[...]
> > I see q=31.0. (the output file is only 5.9 MB)
[...]
> >
Am Di., 25. Juni 2019 um 14:15 Uhr schrieb Ulf Zibis :
> my input is a 1.5 minute mp4 video with 19.5 MB
>
> When I use (with build from dev):
> ./ffmpeg in.mp4 -c:a copy out.mp4
You do not specify an encoder here, mp4 defaults to x264.
> ffmpeg version N-93873-g6276b4db97 Copyright (c)
Am 25.06.19 um 14:15 schrieb Ulf Zibis:
> Hi,
>
> my input is a 1.5 minute mp4 video with 19.5 MB
>
> When I use (with build from dev):
> ./ffmpeg in.mp4 -c:a copy out.mp4
> ffmpeg version N-93873-g6276b4db97 Copyright (c) 2000-2019 the
> FFmpeg developers
> built with gcc 7 (Ubuntu
Hi,
my input is a 1.5 minute mp4 video with 19.5 MB
When I use (with build from dev):
./ffmpeg in.mp4 -c:a copy out.mp4
ffmpeg version N-93873-g6276b4db97 Copyright (c) 2000-2019 the
FFmpeg developers
built with gcc 7 (Ubuntu 7.4.0-1ubuntu1~18.04)
in the output lines e.g.
frame=
18 matches
Mail list logo
