Audio as track 1?
rafael2k opened this issue · 18 comments
When encoding audio-only content, is the audio set to track 1? How to set to track 1?
The audio is always set to track 2, currently. Is this an issue?
I'm seeing some warnings when decoding with ffmpeg's libavcodec, something like "track 1 not found" (and indeed, it does not exist, as only track 2 is present in an audio-only file).
The problem only occurs when I seek to some random file position. I get:
[matroska,webm @ 0x7f30f0000bc0] Invalid track number 1
But indeed, the playback is perfect, without any issue.
Mh, I see. I could make it so that audio gets track number 1 if there is no video track and you could check if it still errors. Thought the track numbers didn't matter and only uniqueness did. Let's hope it's not ffmpeg being confused by there being no video track
I can try it. Should I just hardcode AUDIOTRACK to 1 in the source and check if the warning still occurs?
Yes do that
Let me know if your change fixed your issue! If so, I'll write a proper fix for into the library itself and publish that.
So, setting AUDIO to track 1 and video to track 2, I get:
[matroska,webm @ 0x7f45dc265180]Invalid track number 2
I think there is a need to also remove the reference for the video track in some header, right?
How did you change the code? If I'm not mistaken, you'll simply need to swap the values of these two constants:
webm-muxer/build/webm-muxer.js
Line 432 in fb38fc1
And then simply don't specify a video track for the muxer and none should be included.
I just swapped the track numbers, indeed, as you mention. But now track 2 shows up as invalid in the warning by ffmpeg matroska/webm demuxer (and I did not specified no video track to the muxer).
This is what mkvinfo shows. I think there should be an issue with ffmpeg demuxer, not really with webm-muxer... [EDIT: please read the following comment - I found the issue!]
- EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ Maximum EBML ID length: 4
|+ Maximum EBML size length: 8
|+ Document type: webm
|+ Document type version: 2
|+ Document type read version: 2 - Segment: size 101123
|+ Seek head (subentries will be skipped)
|+ Segment information
| + Timestamp scale: 1000000
| + Multiplexing application: https://github.com/Vanilagy/webm-muxer
| + Writing application: https://github.com/Vanilagy/webm-muxer
| + Duration: 00:00:11.300000000
|+ Tracks
| + Track
| + Track number: 1 (track ID for mkvmerge & mkvextract: 0)
| + Track UID: 1
| + Track type: audio
| + Codec ID: A_OPUS
| + Codec's private data: size 19
| + EBML void: size 4071
| + Audio track
| + Sampling frequency: 48000
| + Channels: 2
|+ Cluster
Found the issue. It is related to the cues. Eg (audio is track 1, there is no video):
|+ Cues
| + Cue point
| + Cue time: 00:00:00.000000000
| + Cue track positions
| + Cue track: 2
| + Cue cluster position: 4325
| + Cue point
| + Cue time: 00:00:01.000000000
| + Cue track positions
| + Cue track: 2
| + Cue cluster position: 12837
| + Cue point
| + Cue time: 00:00:02.000000000
| + Cue track positions
| + Cue track: 2
| + Cue cluster position: 21350
Using stock webm-muxer, without change, when creating an audio-only file (where audio track is nr. 2), I get:
|+ Cues
| + Cue point
| + Cue time: 00:00:00.000000000
| + Cue track positions
| + Cue track: 1
| + Cue cluster position: 4325
| + Cue point
| + Cue time: 00:00:01.000000000
| + Cue track positions
| + Cue track: 1
| + Cue cluster position: 12837
| + Cue point
| + Cue time: 00:00:02.000000000
| + Cue track positions
| + Cue track: 1
| + Cue cluster position: 21350
| + Cue point
| + Cue time: 00:00:03.000000000
| + Cue track positions
| + Cue track: 1
| + Cue cluster position: 29863
| + Cue point
| + Cue time: 00:00:04.000000000
| + Cue track positions
| + Cue track: 1
| + Cue cluster position: 38536
Ah, I see what the bug is now! I had hardcoded the cues to always point to the video track, disregarding the fact that it might not be there. I just published a new version that should fix this issue. Could you try it out?
Yes, will try it now, tks!
Cues are appearing in track 2 now! Seems all good now, and libavcodec matroska demuxer does not complain anymore. Yay!
Awesome! Thanks for cooperating.
Thank you for the awesome muxer!