StaZhu/fix-webm-meta

Filter unknown elements

Closed this issue · 9 comments

Some times the recorder can create unknown entries . . . just need to change

decoder
    .decode(bufSlices)
    .forEach((elm) => reader.read(elm));

to

decoder
    .decode(bufSlices)
    .filter((el) => el.type !== 'unknown')
    .forEach((elm) => reader.read(elm));

Can you provide a sample? I have never encounter this issue before

In some really weird cases I have seen this

image

if you can point us what can cause those it would be awesome, we got this one in a 3 gig recording and it appeared only one time in the entire 90 minutes.

I've received the exact same error, including the exact same properties:

{
    "EBML_ID": "55b0",
    "schema": {
        "name": "unknown",
        "level": -1,
        "type": "unknown",
        "description": "unknown"
    },
    "type": "unknown",
    "name": "unknown",
    "level": -1,
    "tagStart": 189,
    "tagEnd": 191,
    "sizeStart": 191,
    "sizeEnd": 192,
    "dataStart": 192,
    "dataEnd": 208,
    "dataSize": 16,
    "data": {
        "type": "Buffer",
        "data": [
            85,
            177,
            129,
            1,
            85,
            185,
            129,
            1,
            85,
            186,
            129,
            13,
            85,
            187,
            129,
            1
        ]
    }
}

I believe this might be related to VP9. It happens consistently when I create a webm using MediaRecorder(stream, { mimeType: 'video/webm;codecs=vp9,opus' }). The length of the video or filesize do not matter.

It appears to be this issue: legokichi/ts-ebml#33

It appears to be this issue: legokichi/ts-ebml#33

Hey @kirbysayshi , I will update matroska-schema to v4 version today, and release a new package, thanks for you feedback

Btw I also suggest you to use H264 instead of VP9 due to performce issue, since H264 is the only supported hardware encode codec on macOS

@StaZhu I ran into some other issues you should probably be aware of. I attempted to work around the unknown elements problem by forcing the newest version of matroska in my dependency tree. This was enough to bypass the error in this issue! But unfortunately it raised a new one: TimecodeScale vs TimestampScale.

My input webm was generated using Chrome's MediaRecorder. The latest version of matroska schema uses TimestampScale, which is supposedly the modern name. But Chrome still produces TimecodeScale, which causes this unknown problem again!

From https://www.matroska.org/technical/notes.html:

Historically timestamps in Matroska were mistakenly called timecodes. The Timestamp Element was called Timecode, the TimestampScale Element was called TimecodeScale, the TrackTimestampScale Element was called TrackTimecodeScale and the ReferenceTimestamp Element was called ReferenceTimeCode.

I think the longer-term fix is to somehow bypass unknown schema elements, and still be able to write them back into the output file. Currently writing/encoding the unknown elements is what fails.

Btw I also suggest you to use H264 instead of VP9 due to performce issue, since H264 is the only supported hardware encode codec on macOS

I wish I could! Unfortunately, H264 is not supported by Firefox:

MediaRecorder.isTypeSupported('video/webm;codecs=h264')
> false

@kirbysayshi I Think we should submit a crbug to chrome for this

I'm experiencing the same problem. The problem only occurs in chrome on mac. Before switching to this library to support larger files, we used this fix to make ts-ebml work on mac.