Mismatch between exception throw and catch

[moveman]

Is it expected call like m_reader.skipBits(8) will throw bitstreamException but the function will catch VodCoreException only? This caused exception to be thrown when m_reader has not enough buffer to read and program aborted. There are multiple places in the code like this. Shall all catch(VodCoreException& e) in hevc.cpp be changed to catch(BitStreamException& e)?

int HevcHdrUnit::deserialize()
{
    int rez = HevcUnit::deserialize();
    if (rez)
        return rez;
    try
    {
        do
        {
            int payloadType = 0;
            unsigned payloadSize = 0;
            int nbyte = 0xFF;
            while (nbyte == 0xFF)
            {
                nbyte = m_reader.getBits(8);
                payloadType += nbyte;
            }
            nbyte = 0xFF;
            while (nbyte == 0xFF)
            {
                nbyte = m_reader.getBits(8);
                payloadSize += nbyte;
            }
            if (m_reader.getBitsLeft() < payloadSize * 8)
            {
                LTRACE(LT_WARN, 2, "Bad SEI detected. SEI too short");
                return 1;
            }
            if (payloadType == 137 && !isHDR10)  // mastering_display_colour_volume
            {
                isHDR10 = true;
                V3_flags |= HDR10;
                HDR10_metadata[0] = m_reader.getBits(32);  // display_primaries Green
                HDR10_metadata[1] = m_reader.getBits(32);  // display_primaries Red
                HDR10_metadata[2] = m_reader.getBits(32);  // display_primaries Blue
                HDR10_metadata[3] = m_reader.getBits(32);  // White Point
                HDR10_metadata[4] = ((m_reader.getBits(32) / 10000) << 16) +
                                    m_reader.getBits(32);  // max & min display_mastering_luminance
            }
            else if (payloadType == 144)  // content_light_level_info
            {
                int maxCLL = m_reader.getBits(16);
                int maxFALL = m_reader.getBits(16);
                if (maxCLL > (HDR10_metadata[5] >> 16) || maxFALL > (HDR10_metadata[5] & 0x0000ffff))
                {
                    maxCLL = (std::max)(maxCLL, HDR10_metadata[5] >> 16);
                    maxFALL = (std::max)(maxFALL, HDR10_metadata[5] & 0x0000ffff);
                    HDR10_metadata[5] = (maxCLL << 16) + maxFALL;
                }
            }
            else if (payloadType == 4 && payloadSize >= 8 && !isHDR10plus)
            {                           // HDR10Plus Metadata
                m_reader.skipBits(8);   // country_code
                m_reader.skipBits(32);  // terminal_provider
                int application_identifier = m_reader.getBits(8);
                int application_version = m_reader.getBits(8);
                int num_windows = m_reader.getBits(2);
                m_reader.skipBits(6);
                if (application_identifier == 4 && application_version == 1 && num_windows == 1)
                {
                    isHDR10plus = true;
                    V3_flags |= HDR10PLUS;
                }
                payloadSize -= 8;
                for (unsigned i = 0; i < payloadSize; i++) m_reader.skipBits(8);
            }
            else
                for (unsigned i = 0; i < payloadSize; i++) m_reader.skipBits(8);
        } while (m_reader.getBitsLeft() > 16);

        return 0;
    }
    catch (VodCoreException& e)
    {
        (void)e;
        return NOT_ENOUGH_BUFFER;
    }
}

[jcdr428]

@moveman agreed, this is weird. I am not clear on the utility of this VodCore. I have replaced one VodCoreException with a BitStreamException in commit a302806, however I don't know whether this can be generalized. @xavery maybe you could advise on this ?

[moveman]

Hi @jcdr428 , @xavery , actually changing to catch BitStreamException cannot help much. The muxed file is still abnormal. Could you check why tsMuxeR failed to mux this https://drive.google.com/drive/folders/1Q-eC7bbNa5KycTCE7iad8rOQQvCi-3Q8?usp=share_link ? The stack trace is like this:

(gdb) bt
#0  0x00007ffff6b32387 in raise () from /lib64/libc.so.6
#1  0x00007ffff6b33a78 in abort () from /lib64/libc.so.6
#2  0x00007ffff7442a95 in __gnu_cxx::__verbose_terminate_handler() () from /lib64/libstdc++.so.6
#3  0x00007ffff7440a06 in ?? () from /lib64/libstdc++.so.6
#4  0x00007ffff7440a33 in std::terminate() () from /lib64/libstdc++.so.6
#5  0x00007ffff7440c53 in __cxa_throw () from /lib64/libstdc++.so.6
#6  0x0000000000547e8a in BitStreamReader::skipBits (this=0x93e3b8, num=8) at ../tsMuxer/bitStream.h:130
#7  0x000000000057f3bb in HevcHdrUnit::deserialize (this=0x93e390) at ../tsMuxer/hevc.cpp:918
#8  0x000000000058386f in HEVCStreamReader::checkStream (this=0x93d480, buffer=0x7ffff5ec0010 "", len=2097152)
    at ../tsMuxer/hevcStreamReader.cpp:90
#9  0x0000000000583f0e in HEVCStreamReader::getTSDescriptor (this=0x93d480, dstBuff=0x7fffffffbbe0 "", blurayMode=false, 
    hdmvDescriptors=false) at ../tsMuxer/hevcStreamReader.cpp:145
#10 0x000000000062f08d in TSMuxer::intAddStream (this=0x93e720, streamName=..., codecName=..., streamIndex=1, params=..., 
    codecReader=0x93d480) at ../tsMuxer/tsMuxer.cpp:172
#11 0x00000000005f4ffb in MuxerManager::preinitMux (this=0x7fffffffd990, outFileName=..., fileFactory=0x0)
    at ../tsMuxer/muxerManager.cpp:149
#12 0x00000000005f53e5 in MuxerManager::doMux (this=0x7fffffffd990, outFileName=..., fileFactory=0x0)
    at ../tsMuxer/muxerManager.cpp:197
#13 0x000000000059bbf7 in main (argc=3, argv=0x7fffffffe088) at ../tsMuxer/main.cpp:758

[jcdr428]

@moveman no error with latest release 7165e3b on w64. What release and OS are you using ?

[moveman]

Hi @jcdr428, thanks for your reply. Right, it seems no error with latest release but the output should be abnormal. If you check the mediainfo (https://sourceforge.net/projects/mediainfo/) of the muxed TS, I remember the video stream is missing in the mediainfo. So the output TS is abnormal.

We are using Nightly build from 2021-02-13-01-46-27 Pre-release. OS is Centos 7.

[lighterowl]

@moveman agreed, this is weird. I am not clear on the utility of this VodCore. I have replaced one VodCoreException with a BitStreamException in commit a302806, however I don't know whether this can be generalized. @xavery maybe you could advise on this ?

Hard to say what the intent was here. A BitStreamException can be thrown by BitStream classes themselves so perhaps it was meant to bubble up and not be caught here. Either way, "mismatched" throw and catch as described here is not necessarily an error.

[jcdr428]

We are using Nightly build from 2021-02-13-01-46-27

Wow. A lot has happened in the 21 months since 2021-02-13...

I remember the video stream is missing in the mediainfo

With w64 and latest release, I have no problems playing the .ts and with its mediainfo. So I can't help.

[moveman]

Hi @jcdr428 , thanks a lot for your time. Indeed latest release work well with the last asset. But I have tried it on another one here https://drive.google.com/drive/folders/1tHIOFF51PNC7qXMncko4Hdjt81ILtgPX?usp=sharing and the output is abnormal. I have also put the muxed TS there. You can see the mediainfo of 0.ts is: The starting PTS is 4985900 (90k) which is also abnormal. Would you also please try muxing this asset and see if you have any idea?

[vagrant@28845f8be915 bin]$ ./tsMuxeR 0.meta 0.ts
tsMuxeR version git-260ffb2. github.com/justdan96/tsMuxer
HEVC muxing fps is not set. Get fps from stream. Value: 25
B-pyramid level 1 detected. Shift DTS to 2 frames
Bad SEI detected. SEI too short
Decoding AAC stream (track 2): Sample Rate: 24KHz  Channels: 2
0.0% complete
Processed 8749 video frames
100.0% complete
Flushing write buffer
Mux successful complete
Muxing time: 0 sec

Many thanks!

[moveman]

Hi @jcdr428, do you confirm the output is abnormal, even muxing with latest release?

[jcdr428]

Hi @moveman, I am away this week. I'll try next week.

[jcdr428]

@moveman ok I think I understand what's the problem: the large -54sec. audio delay is above the 10sec. initial PTS offset. I have changed the initial PTS offset to 10min., please try tomorrows's release.

Edit: actually the best way would be to adapt the PTS offset from the largest detected delay. I'll work on this when I have time.

[jcdr428]

Closing. Can be reopened on request.