Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Filter unknown elements #3

Closed
raideltorres opened this issue Feb 4, 2022 · 9 comments · Fixed by #5
Closed

Filter unknown elements #3

raideltorres opened this issue Feb 4, 2022 · 9 comments · Fixed by #5

Comments

@raideltorres
Copy link

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));
@StaZhu
Copy link
Owner

StaZhu commented Feb 4, 2022

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

@raideltorres
Copy link
Author

raideltorres commented Feb 4, 2022

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.

@kirbysayshi
Copy link

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.

@kirbysayshi
Copy link

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

@StaZhu
Copy link
Owner

StaZhu commented Mar 17, 2022

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

@StaZhu
Copy link
Owner

StaZhu commented Mar 17, 2022

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

@kirbysayshi
Copy link

@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

@StaZhu
Copy link
Owner

StaZhu commented Mar 18, 2022

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

@kmathmann
Copy link
Contributor

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.

@StaZhu StaZhu closed this as completed in #5 Apr 21, 2022
@StaZhu StaZhu pinned this issue Apr 22, 2022
@StaZhu StaZhu unpinned this issue Jun 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants