Just a guess, but you are using nv_surface->height, which appears to have been
rounded up to 1088 while the actual size is 1080. The 1088 is then passed on to
av_image_copy() where it probably tries to read 1920x1088 pixels from the
source, but the source might not have that much memory and so i
Hallo,
ich schicke Dir noch einen weitere Backtrace mit etwas mehr Details:
(gdb) bt
#0 0x7f19eb8e3a3e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00fbc63e in av_image_copy_plane (height=8, bytewidth=7680,
src_linesize=, src=0x7f19ea08f000 "", dst_linesize=out>, dst=) at sr
Le tridi 23 fructidor, an CCXXIV, Paul B Mahol a écrit :
> You feed to nvenc only rgb? what testsrc only supports. Use testsrc2.
That would be more efficient, but with testsrc, lavfi inserts the scale
filter to convert into the requested format anyway.
Regards,
--
Nicolas George
signature.a
>> for fmt in yuv420p nv12 bgr0 rgb0; do
>> ./ffmpeg -f lavfi -i "testsrc=size=1920x1080:duration=10:rate=30"
>> -c:v h264_nvenc -global_quality 20 -pix_fmt "$fmt" -y out_"${fmt}".mkv
>> done
>
> You feed to nvenc only rgb? what testsrc only supports. Use testsrc2.
pix_fmt should make sure it
On 9/8/16, Timo Rothenpieler wrote:
> Am 08.09.2016 um 02:29 schrieb Sven C. Dack:
>> On 08/09/16 00:57, Hendrik Leppkes wrote:
>>> The image copying code was refactored in an earlier patch to be
>>> generic and not rely on hard-coding format info, hence the second part
>>> is not needed anymore.
On 08/09/16 08:46, Timo Rothenpieler wrote:
Am 08.09.2016 um 02:29 schrieb Sven C. Dack:
On 08/09/16 00:57, Hendrik Leppkes wrote:
The image copying code was refactored in an earlier patch to be
generic and not rely on hard-coding format info, hence the second part
is not needed anymore.
This
Am 08.09.2016 um 02:29 schrieb Sven C. Dack:
> On 08/09/16 00:57, Hendrik Leppkes wrote:
>> The image copying code was refactored in an earlier patch to be
>> generic and not rely on hard-coding format info, hence the second part
>> is not needed anymore.
>>
>
> This is not quite accurate. It does
Am 08.09.2016 um 02:29 schrieb Sven C. Dack:
> On 08/09/16 00:57, Hendrik Leppkes wrote:
>> The image copying code was refactored in an earlier patch to be
>> generic and not rely on hard-coding format info, hence the second part
>> is not needed anymore.
>>
>
> This is not quite accurate. It does
On 08/09/16 00:57, Hendrik Leppkes wrote:
The image copying code was refactored in an earlier patch to be
generic and not rely on hard-coding format info, hence the second part
is not needed anymore.
This is not quite accurate. It doesn't explain the seg. fault. This didn't
happen in my patch
On Wed, Sep 7, 2016 at 7:35 PM, Zoran Turalija wrote:
> Today, new commit landed in git [1], but third part of submitted patch is
> missing in that commit. Same part is missing in patchwork [2], too. Maybe
> committer redacted patch, and threw out unneeded third part. It looks like
> patchwork was
10 matches
Mail list logo
