On Thu Aug 18 10:06:01 BST 2016, Jim web wrote:
I've been told that the root cause is that these use HE-AAC
which the MPEG2 TS spec can't correctly describe.
So it is called aac-lc and it is left to the client program
to recognise the actual codec.
On Thu Aug 18 15:15:23 BST 2016, Jim web wrote:
However the new ffprobe reports the result
as having an aac lc soundstream. Not he.
So it seems to have left something set as being aac lc
despite the actual sound being aac he.
Am I misunderstanding something here?
... The audio stream of ALL flash and hls tvmodes is
AAC LC @96kbpsABR.
It's somewhat different with hvf tvmodes:
The lower resolution modes,
hvflow, hvfstd, hvfhigh, hvfvhigh
(which are derived from the
"apple-ipad-hls" mediaset)
have their audio stream encoded as
HE-AACv1 @96kbpsABR
High Efficiency (HE) is just an
encoding profile of AAC LC aimed
at lower bitrates (it is also called
SBR, aac+ etc., see:
https://en.wikipedia.org/wiki/High-Efficiency_Advanced_Audio_Coding
It is an extension of Low Complexity AAC (AAC LC)
optimized for low-bitrate applications such as streaming audio
HE-AAC decoder is very
popular among mobile devices...
The 50fps hvf modes,
hvfsd, hvfhd
(which are derived from "iptv-all" mediaset)
have their audio stream encoded as
AAC LC @128kbpsABR
so Spectral Band Replication IS NOT USED
on those (that is why the encode has increased
"transparency").
I do not have a flavour of Linux to test,
but from what I've read in the GiP Support
Forum, the loss of audio (with some players)
in the "avconv" remuxed MP4 files
is just due to avconv's inability to properly
remux the type of streams contained in the
beeb's hvf modes (which have DTS & PTS
disparities...).
Regards,
Vangelis.
_______________________________________________
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer
