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)
Change History (19)
by , 7 years ago
Attachment: | ffmpeg-20161201-155645.log added |
---|
comment:1 by , 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 , 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 , 7 years ago
I have tested with current git head. Same result. Report output enclosed.
by , 7 years ago
Attachment: | ffmpeg-20161201-172127.log added |
---|
report output of current git head version
comment:4 by , 7 years ago
Now please capture the incoming udp stream without FFmpeg to allow us to reproduce the crash you see.
comment:5 by , 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 , 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 , 7 years ago
Component: | undetermined → avcodec |
---|---|
Keywords: | crash h264 added |
Priority: | normal → important |
Version: | unspecified → git-master |
Please use dd
to produce a smaller sample that still allows to reproduce the crash.
comment:9 by , 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 , 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 , 7 years ago
Keywords: | SIGSEGV added |
---|---|
Status: | new → open |
comment:12 by , 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 , 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 , 7 years ago
Keywords: | h264_cuvid added; h264 removed |
---|
comment:15 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | open → closed |
This was fixed in 6d9a46e884d090a68069112a3b0436aa8b563967 and 9777ba33f52c54cc982f977ce28e5d4b55927b72
report output