Dne 13.2.2017 v 17:07 Philip Langdale napsal(a):
On Mon, 13 Feb 2017 07:21:51 -0800
Philip Langdale <phil...@overt.org> wrote:
On Mon, 13 Feb 2017 08:52:34 +0100
Miroslav Slugeň <thunde...@email.cz> wrote:
I am using current STABLE drivers 375.26, because BETA drivers
378.09 caused some crashes while encoding on NVENC.
I tested this on BETA drivers too and it is still same.
Original workaround is not working anymore :(
INPUT: Stream #0:0[0x401]: Video: mpeg2video (Main) ([2][0][0][0] /
0x0002), yuv420p(tv, top first), 720x576 [SAR 64:45 DAR 16:9], 25
fps, 25 tbr, 90k tbn, 50 tbc
OUTPUT: Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] /
0x001B), yuv420p(progressive), 720x576 [SAR 16:11 DAR 20:11], 25
fps, 25 tbr, 90k tbn, 50 tbc
COMMAND: ffmpeg -deint adaptive -hwaccel cuvid -c:v mpeg2_cuvid -i
"in.ts" -y -c:v h264_nvenc -c:a copy -b:v 1M -preset hq -f mpegts
"out.ts"
Also someone else is complaining about this issue:
http://superuser.com/questions/1174097/ffmpegnvenc-encoding-strange-aspect-ratio
M.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Can you point me to a sample that you see this behaviour with? I
cannot reproduce with DVD sources here, which is where I saw the
original problem.
You sent me a sample and I tried it out. I was able to reproduce your
problem, but it is not the original problem, and I wonder what is
really going on.
If you take your sample and your command line and then output to a
different container (i tried mkv and mp4), it's all correct - and it
would not be correct if my original workaround was still required.
There's something specific about using mpegts that leads to this
problem.
I'm not familiar with what parts of what metadata get respected in
different contextx For example, the out.ts, this command line produces,
is reported as having the right aspect ratio by mediainfo, but the
wrong one by ffprobe (and then plays back wrong, obviously).
Modifying the darWidth and darHeight leads to changes that are visible
in mediainfo, and are cumulative with respect to whatever bug is
hitting you here.
So, theory - there was a bug where nvenc was distorting the DAR and
that bug is now fixed. It seems like there is now some other bug, or
perhaps there always was a bug, which is modifying the SAR. Perhaps it
is doing it all the time but in other containers, container level
metadata is overriding it so it never becomes an issue.
Sounds like a great time for an nvidia dev to chime in :-)
--phil
I am sure that i know what is going on, NVENC is inserting wrong SPS VUI
aspect_ratio_idc to h264 packets when you encode at resolution 720x576
and 720x480
AR 16:9 will insert aspect_ratio_idc=4 but it should be
aspect_ratio_idc=255, sar_width=64, sar_height=45 for 720x576
AR 4:3 will insert aspect_ratio_idc=2 but it should be
aspect_ratio_idc=255, sar_width=16, sar_height=15 for 720x576
MP4 and MKV containers contains correct AR metadata information which
all players should accept, but TS container has nothing like that so it
relies on what is inside h264 SPS.
Miroslav Slugeň
+420 724 825 885
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
