On Mon, May 02, 2016 at 10:35:29AM +0200, Hendrik Leppkes wrote: > On Sun, May 1, 2016 at 11:43 PM, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > > On Sun, May 1, 2016 at 8:30 PM, James Almer <jamr...@gmail.com> wrote: > >> With the samples you shared and with a random lbr-in-wav mono sample i > >> found > >> in the wild i get the following when i try to do a codec copy. > >> Core and every other DTS extension in contrast seem to set timestamps just > >> fine. > >> > > > > Thats probably because DTS Express streams do not have a core stream, > > and without it the parser doesn't know the frame size, hence no > > duration and no timestamps. > > > > On an additional note, this should be entirely independent of being > able to decode it. This behavior should be like this before applying > this, no?
Yes, this only adds LBR decoder and doesn't change anything in the parser. LBR (or other core-less DTS stream like HD MA) should still work when put into container, though. > Unfortunately parsing the EXSS header in the parser to find the > required info would be rather annoying, because the EXSS headers are > much more complex than the dts core headers. There is an easily accessible duration field in EXSS, but that gives frame duration in clock cycles, while parser context seems to require duration in samples and sample rate to be set. Unfortunately, that makes duration calculation rather fragile, since sample rate may change in decoder for various reasons (e.g. sample rate extension fails to decode, core_only is enabled, etc). Not sure how to fix this properly. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
