[mythtv-users] nuvexport audio sync
mythtv-users2 at dwilga-linux1.amherst.edu
Wed May 4 14:18:21 UTC 2011
On May 2, 2011, 12:08 AM, <jyavenard [at] gmail> wrote:
> On 2 May 2011 14:42, Gavin Hurlbut <gjhurlbu [at] gmail> wrote:
> > Ahh. Gotcha. So with what you have now, fifo mode *can* do straight
> > passthrough with another commandline option? That would be kinda
> cool for
> > future functionality in nuvexport. :) Anyways, with your latest
> changes, I
> > guess I'll need to re-tweak to get it working again, which is the
> price we
> > pay for progress.
> The option is --passthrough in the mythtranscode command line. That
> option should be added to the recording profile editor, the problem is
> that unless you're using fifo mode ; the destination container (mp3 or
> nuv) doesn't know how to deal with the resulting data. The NUV
> container can't even have anything else but a mp3 or stereo 16bits PCM
> audio stream
> Previously, avfd would always decode all the channels of the audio
> stream and pass it to mythtranscode ; when most of the time the new
> destination container would have been expecting stereo.
> In FIFO it didn't matter, because that's what fifo does: just output
> all that was decoded.
> The *fix* I'm referring to, only force avfd to only decode stereo and
> pass that to mythtranscode... Adding the ability to handle more than
> stereo isn't complicated as such, but mythtranscode never had any of
> the internal logic to handle different channel numbers. There's not
> even a member variable specifying how many channels we are expecting
> The reason avfd used to decode all channels, was to prevent the issue
> with AC3 audio being at different audio level. The main audio class
> knows how to downmix, but the dummy audio class in mythtranscode has
> no clue of that.
> If there was an easy way to tell how many channels we are expecting in
> the end, I could make avfd decode all channels once again and add a
> downmixer in mythtranscode as required.
> But I'm not sure it's worth fixing mythtranscode if the aim is getting
> a mkv transcoder instead... but the task for that one is daunting.
Let me begin by saying that my familiarity with the various codecs and
containers is pretty limited. This will probably become even more
obvious, the more you read.
So, if I understand correctly, there is no way to pass through all of
the original audio data when transcoding to a .nuv container. Your
solution of going to a .mkv container would be fine for me, but only if
the video could still be compressed with the Xvid/MPEG-4 codec it (I
think?) now uses. I have tried video compressed with H.264, and the user
experience during playback on all of my frontends is just not as smooth.
Not to mention that transcoding to H.264 seems to take significantly
more time and CPU.
Dan Wilga "Ook."
More information about the mythtv-users