Opened 7 years ago
Last modified 4 years ago
#6907 open defect
hevc decoding regression
Reported by: | Evgeniy1990 | Owned by: | |
---|---|---|---|
Priority: | important | Component: | avcodec |
Version: | git-master | Keywords: | hevc regression |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | yes | |
Analyzed by developer: | no |
Description
After the update ffmpeg git-n3.4-dev-2207-geea64ef4fif RAW video files has stopped playing.
Test sample: https://yadi.sk/d/_CMwldVX3QSNxx
Attachments (1)
Change History (7)
comment:1 by , 7 years ago
Component: | ffmpeg → avcodec |
---|---|
Keywords: | hevc regression added |
Priority: | normal → important |
Reproduced by developer: | set |
Status: | new → open |
Summary: | RAW video does not play → hevc decoding regression |
Version: | unspecified → git-master |
by , 7 years ago
Attachment: | Sintel_272p_logo_cut.265 added |
---|
follow-up: 3 comment:2 by , 4 years ago
This is not a RAW video file. It is Annex B HEVC. This is a very strange issue. Not only everything is zero out on HEVC profile and tier and no info about progressive stuff in VPS and SPS; there is 3 sub layers... Now the problem (and regression) with SPS is that it says "Invalid value of delta_poc: -2", and there is indeed one in SPS. Maybe this thing should be unsigned, you know.
follow-ups: 4 5 comment:3 by , 4 years ago
Replying to Balling:
This is not a RAW video file. It is Annex B HEVC. This is a very strange issue. Not only everything is zero out on HEVC profile and tier and no info about progressive stuff in VPS and SPS; there is 3 sub layers... Now the problem (and regression) with SPS is that it says "Invalid value of delta_poc: -2", and there is indeed one in SPS. Maybe this thing should be unsigned, you know.
Making it unsigned will not change the fact the coded value is wrong. It should be between 0 and 32767, yet it's 4294967293 in the bitstream.
So changing the type and adapting the error check will still make it fail. The only "solution" would be to remove the check altogether and allow out of range values again.
comment:4 by , 4 years ago
Replying to jamrial:
Yeah, this value is delta_poc_minus_1, which means the actual value is -3 (in the bitstream).
The real solution here will be to allow decoding even with invalid SPS, instead of READING ALL (!) of NALs after that WITH an error. This is just wow, why it cannot exit immediately if it is that problematic? Cannot it understand that it will not be able to decode further?
Ah, yes, BTW, it regressed further. Now it does not stop decoding.
follow-up: 6 comment:5 by , 4 years ago
Replying to jamrial:
Making it unsigned will not change the fact the coded value is wrong. It should be between 0 and 32767, yet it's 4294967293 in the bitstream.
So changing the type and adapting the error check will still make it fail. The only "solution" would be to remove the check altogether and allow out of range values again.
is it always 4294967293 and always at position 1 ?
if so then only that would need to be allowed, also it would need to be checked that such out of range value doesnt have any unintended downstream effects.
Also strictly speaking simply removing the check is likely not enough as that would likely require a 32bit int
comment:6 by , 4 years ago
Replying to michael:
It is not at position 1. Not even close, there is a complicated tree and this one value is almost at the end of SPS. All others delta_poc_minus_1 are good though.
For future tickets:
Please remember to provide a simplified command line that allows to reproduce the issue together with the console output.
Regression since 2b44dcbc44e99daf9515753e9fd4c2e1ea53a2fa