Opened 11 months ago

Closed 5 months ago

#5985 closed defect (fixed)

error decoding h264 stream with h264_cuvid in udp mpegts

Reported by: doubleb 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 doubleb 11 months ago.
report output
gdb.txt (10.8 KB) - added by doubleb 11 months ago.
gdb output
valgrind.txt (2.0 KB) - added by doubleb 11 months ago.
valgrind output
ffmpeg-20161201-172127.log (304.8 KB) - added by doubleb 11 months ago.
report output of current git head version

Download all attachments as: .zip

Change History (19)

Changed 11 months ago by doubleb

report output

Changed 11 months ago by doubleb

gdb output

Changed 11 months ago by doubleb

valgrind output

comment:1 Changed 11 months ago by cehoyos

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 Changed 11 months ago by doubleb

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 Changed 11 months ago by doubleb

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

Changed 11 months ago by doubleb

report output of current git head version

comment:4 Changed 11 months ago by cehoyos

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

comment:5 Changed 11 months ago by doubleb

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 Changed 11 months ago by doubleb

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 Changed 11 months ago by cehoyos

  • Component changed from undetermined to avcodec
  • Keywords crash h264 added
  • Priority changed from normal to important
  • Version changed from unspecified to git-master

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

comment:8 Changed 11 months ago by doubleb

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

Last edited 11 months ago by doubleb (previous) (diff)

comment:9 Changed 11 months ago by cehoyos

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

comment:10 Changed 11 months ago by doubleb

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

comment:11 Changed 11 months ago by cehoyos

  • Keywords SIGSEGV added
  • Status changed from new to open

comment:12 Changed 11 months ago by oromit

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 Changed 11 months ago by doubleb

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 Changed 7 months ago by cehoyos

  • Keywords h264_cuvid added; h264 removed

comment:15 Changed 5 months ago by oromit

  • Resolution set to fixed
  • Status changed from open to closed
Note: See TracTickets for help on using tickets.