[FFmpeg-devel] [PATCH] avcodec/opus_parser: Handle complete frames flag.

Hendrik Leppkes h.leppkes at gmail.com
Fri Aug 24 03:52:59 EEST 2018


On Thu, Aug 23, 2018 at 10:43 PM James Almer <jamrial at gmail.com> wrote:
>
> On 8/21/2018 7:47 PM, James Almer wrote:
> > On 8/20/2018 3:35 PM, Jacob Trimble wrote:
> >> I am not entirely sure what this flag is supposed to be, since there
> >> is no documentation where it is defined.  But this was suggested by
> >> James Almer as a fix for my encrypted Opus problems and several other
> >> codec parsers do the same thing.
> >
> > It's a flag that lets the parser know what kind of frames it's getting.
> > libavformat will set it if the source is a demuxer that guarantees the
> > propagation of complete frames, like mp4, Matroska and Ogg.
> >
> > Applied, thanks.
>
> Had to revert this as it broke packet timestamp and duration generation
> for all Opus streams in Matroska and probably other containers.
> You can reproduce it with the mka test vectors in the FATE sample suite
> by doing a codec copy to the framecrc pseudo muxer. Decoding was
> apparently unaffected, so FATE didn't detect any regression.
>
> I don't know how to work around the issues you had with encrypted files
> if not with this. Maybe the Opus packet parsing could be done by the
> Matroska demuxer, much like the Ogg demuxer does (The only container
> apparently not negatively affected by the commit i just reverted).

You could probably fix that by refactoring opus_find_frame_end to
split the frame boundary finding and the actual packet header parsing
(which sets the duration info).

But it might be more interesting why it fails with encrypted streams
in the first place. Does it encrypt the entire frame, including frame
headers? Because if that would be the case, that change would not help
anylonger.
Maybe if a demuxer can know that, it should just set a flag to disable
parsing entirely then.

- Hendrik


More information about the ffmpeg-devel mailing list