Open
Bug 1321246
Opened 8 years ago
Updated 2 years ago
Opus in MP4, not taking into account Discard padding
Categories
(Core :: Audio/Video: Playback, defect, P3)
Core
Audio/Video: Playback
Tracking
()
NEW
Tracking | Status | |
---|---|---|
platform-rel | --- | + |
People
(Reporter: jya, Unassigned)
References
Details
(Whiteboard: [platform-rel-Vimeo])
As seen in bug 1319992. The opus decoder requires specific fields to be set to handle pre-skip and discard padding to be set. The MP4 demuxer doesn't appear to set anything... It's also the same for other audio codec in MP4, but I'll open another bug for that.
Comment 1•8 years ago
|
||
The mp4 demuxer provides pre-skip and codec delay values in the codec-specific just like the webm demuxer does. Is this code not working? https://dxr.mozilla.org/mozilla-central/source/media/libstagefright/binding/MP4Metadata.cpp#805 https://dxr.mozilla.org/mozilla-central/source/media/libstagefright/binding/mp4parse_capi/src/lib.rs#482
Reporter | ||
Comment 2•8 years ago
|
||
ok. So it's good for preskip. However, there's definitely no allowance for the number of frames to trim at the end of the media. That is an information that should be set on the last demuxed frame only. Webm has a specific entry on the block you need to apply it to (https://www.matroska.org/technical/specs/index.html DiscardPadding) and for ogg it's always the last block
Reporter | ||
Updated•8 years ago
|
Summary: Opus in MP4, not taking into account PreSkip and Discard padding → Opus in MP4, not taking into account Discard padding
Comment 3•8 years ago
|
||
I think one is supposed to use the EDIT list for end trimming in mp4. https://opus-codec.org/docs/opus_in_isobmff.html#4.4 Right now the rust parser just copies stagefright's duration calculation, so it's possible they're both wrong.
Reporter | ||
Comment 4•8 years ago
|
||
The opus decoder makes no consideration of the packet duration. Which would be difficult anyway as the two containers where opus is most used have no duration concept. We need an explicit way in the demuxer to flag the specific sample where the trimming is to occur. Long term we want to remove the concept of block duration too. With fragmented MP4, it gets further complicated in that the last sample of a block may not need to be trimmed. The specific handling of webm is better here. There's an explicit trimming value set.
Updated•8 years ago
|
Priority: -- → P3
Updated•8 years ago
|
platform-rel: --- → ?
Whiteboard: [platform-rel-Vimeo]
Updated•8 years ago
|
platform-rel: ? → +
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•