Opened 7 years ago

Closed 7 years ago

#5985 closed defect (fixed)

error decoding h264 stream with h264_cuvid in udp mpegts

Reported by: Bela B Owned by:
Priority: important Component: avcodec
Version: git-master Keywords: crash SIGSEGV h264_cuvid
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:
ffmpeg crashed, see the log-report, gdb and valgrind output below

the incoming multi-program transport stream contains several programs.
They have mpeg2 or h264 video streams.
There is no any problem decoding mpeg2 videostream with mpeg2_cuvid.
If I capture the h264 stream into mp4 files and then decoding the video stream in mp4 container by h264_cuvid works well without error. So I think the error not relates to video content but to udp protocol.

Attachments (4)

ffmpeg-20161201-155645.log (328.4 KB ) - added by Bela B 7 years ago.
report output
gdb.txt (10.8 KB ) - added by Bela B 7 years ago.
gdb output
valgrind.txt (2.0 KB ) - added by Bela B 7 years ago.
valgrind output
ffmpeg-20161201-172127.log (304.8 KB ) - added by Bela B 7 years ago.
report output of current git head version

Download all attachments as: .zip

Change History (19)

by Bela B, 7 years ago

Attachment: ffmpeg-20161201-155645.log added

report output

by Bela B, 7 years ago

Attachment: gdb.txt added

gdb output

by Bela B, 7 years ago

Attachment: valgrind.txt added

valgrind output

comment:1 by Carl Eugen Hoyos, 7 years ago

Please test current FFmpeg git head.

How did you capture the h264 stream into mp4? I would expect that when you capture the udp stream, the output would not be mp4, but mpegts. aviocat should be able to do this (as are probably many other simple tools).

comment:2 by Bela B, 7 years ago

capture: I mean without transcodng:

./ffmpeg_g -report -v 9 -loglevel 99 -y -f mpegts -i "udp://239.100.1.101:1001?buffer_size=2000000&fifo_size=2000000&overrun_nonfatal=0" -map "0:#0x9c4" -map "0:#0x9c5" -vcodec copy -acodec copy /tmp/bbcopy.mp4

and after it transcoding:

./ffmpeg_g -report -v 9 -loglevel 99 -y -vcodec h264_cuvid -f mpegts -i /tmp/bbcopy.mp4 -vcodec libx264 -preset fast -s 640x360 -g 25 -vb 800k -bufsize 3000k -r 25 -maxrate 1200k -profile:v high -level 4.0 -pix_fmt yuv420p -acodec libfdk_aac -cutoff 20000 -ac 2 -ar 44100 -ab 192k /tmp/bbout.mp4

it works as expected.

But I need on-the-fly transcoding.

I will test with current git very soon.

comment:3 by Bela B, 7 years ago

I have tested with current git head. Same result. Report output enclosed.

by Bela B, 7 years ago

Attachment: ffmpeg-20161201-172127.log added

report output of current git head version

comment:4 by Carl Eugen Hoyos, 7 years ago

Now please capture the incoming udp stream without FFmpeg to allow us to reproduce the crash you see.

comment:5 by Bela B, 7 years ago

I have made the capturing. I have checked, and the crash is reproducible with resulted ts file.

ffmpeg -y -vcodec h264_cuvid -f mpegts -i /tmp/full.ts -map "0:#0x9c4" -map "0:#0x9c5" -vcodec libx264 -preset fast -s 640x360 -g 25 -vb 800k -bufsize 3000k -r 25 -maxrate 1200k -profile:v high -level 4.0 -pix_fmt yuv420p -acodec libfdk_aac -cutoff 20000 -ac 2 -ar 44100 -ab 192k /tmp/bbout.mp4

I gladly upload this file to you but your upload.ffmpeg.org ftp server seems down, currently.
So, I have made the ts file available at http://download.songo.hu/full.ts

comment:6 by Bela B, 7 years ago

I have found a workaround namely specifying exactly the stream to apply the decoding:

instead of this: -vcodec h264_cuvid -f mpegts -i ....
using this: -codec:#0x9c4 h264_cuvid -f mpegts -i ...

(see the originly enclosed log file for full command line)

comment:7 by Carl Eugen Hoyos, 7 years ago

Component: undeterminedavcodec
Keywords: crash h264 added
Priority: normalimportant
Version: unspecifiedgit-master

Please use dd to produce a smaller sample that still allows to reproduce the crash.

comment:8 by Bela B, 7 years ago

Is 200M acceptable sample size instead of the current 500M?

Last edited 7 years ago by Bela B (previous) (diff)

comment:9 by Carl Eugen Hoyos, 7 years ago

Of course! If the given stream does not crash for a size of 190MB but crashes for 200MB, please provide 200MB.

comment:10 by Bela B, 7 years ago

I have created a 20MB ts file that you can reproduce the crash with.
http://download.songo.hu/full20.ts

comment:11 by Carl Eugen Hoyos, 7 years ago

Keywords: SIGSEGV added
Status: newopen

comment:12 by Timo R., 7 years ago

There is something strange going on here, the problem is in the has_decode_delay_been_guessed function in libavformat/utils.c.

Setting a breakpoint there, I at some point get this result in gdb:

(gdb) print st->codecpar->codec_id
$8 = AV_CODEC_ID_H264
(gdb) print st->internal->avctx->codec_id
$9 = AV_CODEC_ID_MPEG2VIDEO

So from what I figure, it seems like the codecpar codec_id is set to h264, due to the decoder being forced to a h264 decoder on the commandline, while the underlying codec is actually mpeg2.

It looks like the fix would be to extend the initial check for h264 to also check the internal codec being used.

comment:13 by Bela B, 7 years ago

I have made further tests and saw that there is no any problem if there is only one program stream in the the mpeg-ts even with h264 video. Maybe relates this bug to that mpegts has several programs with several mpeg2 and h264 videos streams and ffmpeg tries to figure out video codec id according to first available video stream but not according to the selected video stream? and when the first available video stream is mpeg2 then occurs this situation?

comment:14 by Carl Eugen Hoyos, 7 years ago

Keywords: h264_cuvid added; h264 removed

comment:15 by Timo R., 7 years ago

Resolution: fixed
Status: openclosed
Note: See TracTickets for help on using tickets.