Am 11.01.19 um 01:47 schrieb Carl Eugen Hoyos:
> 2019-01-11 0:39 GMT+01:00, Ulf Zibis :
>
>> can anybody explain me the data of ffprobe, I don't find enough hints in
>> the docu. E.g.:
>> $ ffprobe CYD_copy.vob
>> Input #0, mpeg, from 'CYD_copy.vob':
>> Duration: 01:16:20.74, start: 0.50, bi
Hi again,
Am 06.01.19 um 14:27 schrieb Ulf Zibis:
> because of a noise in the 1st line of my video, I want to duplicate the
> 2nd line to the first. I tried this and got an error about invalid
> horizontal crop value:
> ffmpeg -i in.vob -vf
> "split[in1][in2];[in1]crop=in_w:1:0:1[top];[in2]crop=in
Hi Moritz,
Am 02.02.19 um 22:29 schrieb Moritz Barsnick:
> You can always "up-convert" your colorspace before cropping, and
> "down-convert" afterwards:
> $ ffmpeg [...] -vf format=yuv444p,crop=h=1:...,format=yuv420p [...]
> or something like this.
Much thank for this hack ... it works!
For the r
2019-02-02 23:02 GMT+01:00, Felix Muster :
> I'm trying to convert DTS-HD Master Audio track embedded
> in mkv container to alac and mux it into mp4(m4v)-container.
> After the half I get the following messages:
Please provide the input sample.
Carl Eugen
Hello,
I'm trying to convert DTS-HD Master Audio track embedded in mkv container to
alac and mux it into mp4(m4v)-container.
After the half I get the following messages:
[dca @ 02a7bb80] Failed to decode block code(s)
Error while decoding stream #0:1: Invalid data found when processing inp
On Sat, Feb 02, 2019 at 21:22:03 +0100, Ulf Zibis wrote:
> Does that mean, it makes *sense to file a bug* to have single line
> processing with crop in the future? I would burn for that.
You can always "up-convert" your colorspace before cropping, and
"down-convert" afterwards:
$ ffmpeg [...] -vf
Am 02.02.19 um 02:18 schrieb Carl Eugen Hoyos:
>> I meant, if libx264 does a re-encoding from interlaced
>> encoding to progressive encoding?
> libx264 does not encode "from interlaced encoding"
> because it cannot know if the source was encoded
> interlaced or progressive.
With "interlaced encod
Am 02.02.19 um 19:27 schrieb Ulf Zibis:
> But if I have a interlaced encoded stream with interlaced content, I
> guess only both steps at same time ensure to get a progressive stream
> with good visual quality.
For this case I see 2 options. Assume we have a 25 fps top first
interlaced encoded st
>Correction:
>
>./ffmpeg -init_hw_device cuda=0 -filter_hw_device 0 -i ../4k_normal.mp4 -vf
>format=nv12,hwupload,scale_npp=1280:720 -c:v h264_nvenc 720p1.mp4
OK that is good
$ time ./ffmpeg -init_hw_device cuda=0 -filter_hw_device 0 -i
../4k_normal.mp4 -vf format=nv12,hwupload,scale_npp=1280
When displaying a frame count number in the drawtext filter, the varying height
of the characters can make the text jitter vertically as they count. Its
possible to stop this by applying the ‘ascent' value to the y coordinate.
However when the drawtext filter contains a box, this element also ji
Am 02.02.2019 um 19:28 schrieb Paul B Mahol:
On 2/2/19, Michael Koch wrote:
Am 02.02.2019 um 19:01 schrieb Paul B Mahol:
On 2/2/19, Michael Koch wrote:
Hi all,
I have two suggestions for improvement:
1. It would be nice if the curves filter could import curves files from
GIMP. GIMP can exp
On 2/2/19, Michael Koch wrote:
> Am 02.02.2019 um 19:01 schrieb Paul B Mahol:
>> On 2/2/19, Michael Koch wrote:
>>> Hi all,
>>>
>>> I have two suggestions for improvement:
>>>
>>> 1. It would be nice if the curves filter could import curves files from
>>> GIMP. GIMP can export curves files in two
Am 02.02.19 um 18:38 schrieb Carl Eugen Hoyos:
> 2019-02-01 23:46 GMT+01:00, Ulf Zibis :
>> Am 30.01.19 um 15:08 schrieb Carl Eugen Hoyos:
>>> Without interpolation, this is what all video players do if you disable
>>> all de-interlacing.
>>> The problem is what kind of "interpolation" you use, th
Am 02.02.2019 um 19:01 schrieb Paul B Mahol:
On 2/2/19, Michael Koch wrote:
Hi all,
I have two suggestions for improvement:
1. It would be nice if the curves filter could import curves files from
GIMP. GIMP can export curves files in two different formats, either the
default format or the "ol
On 2/2/19, Michael Koch wrote:
> Hi all,
>
> I have two suggestions for improvement:
>
> 1. It would be nice if the curves filter could import curves files from
> GIMP. GIMP can export curves files in two different formats, either the
> default format or the "old curves file format". For the old f
2019-02-01 23:46 GMT+01:00, Ulf Zibis :
>
> Am 30.01.19 um 15:08 schrieb Carl Eugen Hoyos:
>> Without interpolation, this is what all video players do if you disable
>> all de-interlacing.
>> The problem is what kind of "interpolation" you use, this is called
>> de-interlacing, an endless number of
On Sat, 2 Feb 2019 at 19:39, Mahmood Naderan wrote:
> >Using your sample above:
> >
> >./ffmpeg -init_hw_device cuda=0 -i ../4k_normal.mp4 -vf
> >format=nv12,hwupload,scale_npp=1280:720 -c:v h264_nvenc 720p1.mp4
> >
> >Try that and report back.
> >
> >
>
> It fails
>
>
> $ time ./ffmpeg -init_hw_
Sorry for top posting, I can’t figure out how to preserve the formatting while
editing from the bottom with this Yahoo Mail mobile editor...
“OK, my understandig was, "de-interlacing" means to re-encode from
interlaced to progressive _and_ do some interpolation or whatever stuff.”
Not entirely bu
Hi all,
I have two suggestions for improvement:
1. It would be nice if the curves filter could import curves files from
GIMP. GIMP can export curves files in two different formats, either the
default format or the "old curves file format". For the old format I
have a selfmade C# converter to
>Using your sample above:
>
>./ffmpeg -init_hw_device cuda=0 -i ../4k_normal.mp4 -vf
>format=nv12,hwupload,scale_npp=1280:720 -c:v h264_nvenc 720p1.mp4
>
>Try that and report back.
>
>
It fails
$ time ./ffmpeg -init_hw_device cuda=0 -i ../4k_normal.mp4 -vf
format=nv12,hwupload,scale_npp=1280:720
On Sat, 2 Feb 2019 at 18:47, Mahmood Naderan wrote:
> >Then don't use the cuda filter.
>
> So, my time measurements show that
>
> CPU: ./ffmpeg -i ../4k_normal.mp4 -vf scale=1280:720 720p1.mp4
> real0m23.748s
>
> GPU: ./ffmpeg -hwaccel cuvid -c:v h264_cuvid -i ../4k_normal.mp4 -vf
> scale_n
On Sat, 2 Feb 2019 at 19:09, Mahmood Naderan wrote:
> >Note that hardware accelerated
> >decode is targeted for real time PLAYBACK without using any CPU resources,
> >and does not necessarily imply to be faster than a software based decode.
>
> If I got the point, you are saying that GPU version
>Note that hardware accelerated
>decode is targeted for real time PLAYBACK without using any CPU resources,
>and does not necessarily imply to be faster than a software based decode.
If I got the point, you are saying that GPU version is somehow used to free
CPU cores, so that CPU cores are ready
On Thu, Jan 31, 2019, 22:45 Mahmood Naderan Hi,
> I want to run a multicore CPU job with ffmpeg and I think the command
> should be
>
> ./ffmpeg -i ../4k_normal.mp4 -vf scale_npp=1280:720 720p1.mp4
>
> but it fails
>
> ./ffmpeg -i ../4k_normal.mp4 -vf scale_npp=1280:720 720p1.mp4
> ffmpeg versio
>Then don't use the cuda filter.
So, my time measurements show that
CPU: ./ffmpeg -i ../4k_normal.mp4 -vf scale=1280:720 720p1.mp4
real0m23.748s
GPU: ./ffmpeg -hwaccel cuvid -c:v h264_cuvid -i ../4k_normal.mp4 -vf
scale_npp=1280:720 -c:v h264_nvenc 720p1.mp4
real0m20.889s
Do you thi
25 matches
Mail list logo
