translate: explicit format destination not properly set
authorKevin Harwell <kharwell@digium.com>
Wed, 13 Jul 2016 22:45:27 +0000 (17:45 -0500)
committerKevin Harwell <kharwell@digium.com>
Wed, 13 Jul 2016 22:45:27 +0000 (17:45 -0500)
commit63ac4c9487ee085755c991813ec7e5994bf7ccc2
tree883757ca9ea7faeb3d7dc184d42b64f88be3bdec
parente0f27ecabb2ff766ea4ec7bdd77fccab2fe826c4
translate: explicit format destination not properly set

If the destination format's name differed from the codec name then the
translator's explict_dst field would be improperly set. In some circumstances
it would end up setting it to a newly created format that has the same name
as the codec when it actually needed to be the given destination codec.

This could cause the translation path to use the wrong format. For instance,
if an endpoint had specified 'myulaw' as a format the translator could end up
using a 'ulaw' format (with whatever/default settings) instead. If the format
attribute settings differed between the two then there may unexpected results
during processing.

This patch removes the name check when building the translation path. This
should make it always set the translator's explicit_dst to the given destination
format as long as the sample rate and types match.

Change-Id: Iaf8a03831d68e657d89569d54b505074efbefab5
main/translate.c