Failure to record HEVC/4K broadcast #620
Comments
kmdewaal
added
version:master
|
I don't see how 7b2ac1e would introduce a problem; I'll have to look at the FFmpeg headers again to compare and see if there are any subtle differences. Since this is a recording issue, a log from Edit: The FFmpeg headers are not very readable, but the only functional differences I saw were around invalid input data. |
|
I do not understand what is the problem that is being solved by using your Bitreader functions instead of ffmpeg. |
|
The point of that commit is to not use the internal FFmpeg headers |
|
The change also removed this below const from the calculation of rbsp buffer: |
That could be a significant difference. Because MythTV didn't define
|
|
@kmdewaal Could you upload a log from I would also like to clarify a few things about what specifically does/does not work:
|
|
As it is rather difficult to analyze this problem from a distance I did a bit of investigation. The problem happens when br.get_ue_golomb() returns a negative integer value, probably -1. It is of course possible, and probably a good idea, to protect the code in HEVCParser.cpp against negative values. However, I do not think it is a good idea to make the BitReader behave different compared to the FFmpeg code it replaces, and then modify all the software that uses this. |
|
That line was always incorrect: So, in my opinion, your fix looks good to me, although I would have called the loop variable I'm not sure why it worked with FFmpeg's version, though. For reference, AVERROR_INVALIDDATA = -1094995529, which is what FFmpeg would return on error. From ITU-T-REC-H.265-202108-I!!PDF-E.pdf page 74: "The value of Could you add these extra log statements and let me know what they print? |
In parseVPS the value of vps_num_layer_sets_minus1 should always be zero or positive. The value is returned by get_ue_golomb() but this is an int where a negative value is used to signal an error status. Copying a negative value into an unsigned int and using that as a loop counter limit results in an almost endless loop. The negative value is observed incidentally with 4K HEVC recordings after the change from FFmpeg to BitReader in commit 7b2ac1e. However, also the FFmpeg version of get_ue_golomb() can return negative values although this has never been observed. This issue is now fixed by comparing int instead of unsigned int values. Additionally, a warning message is given when the value returned by get_ue_golomb() is negative when reading the vps_num_layer_sets_minus1 value. This problem does happen only incidentally; it is possible that it is caused by either invalid or unexpected HEVC stream content. However, that is what is being broadcast and MythTV should be able to handle it. It might also be possible that this issue is related to how close the reading is to the head of the recording but this has not been further investigated. Note that the get_ue_golomb() function is used in more places in HEVCParser.cpp and in some of these places the code will fail horribly when a negative value is returned. More fixes might be needed to make HEVCParser more resilient. Refs #620
|
Today the problem cannot be reproduced anymore on the 4K HEVC cable channel that previously consistently failed to record. Whether that is due to the latest updates to master or to a change in the cable signal is difficult to say. |
MythTV master cannot record 4K broadcast from my cable signal. The same channel can be recorded OK with fixes/32.
Symptoms are zero-byte recordings and a backend that cannot be stopped with a single Ctrl-C.
The frontend gives the following messages:
The problem is introduced by the following commit:
The text was updated successfully, but these errors were encountered: