[mythtv-users] Missing --passthrough option in mythtranscode

[Paul Gardiner]

On 07/06/2011 13:59, Jean-Yves Avenard wrote:
> On 7 June 2011 20:37, Paul Gardiner<lists at glidos.net>  wrote:
>> Not quite, but close I think. The audio passes through perfectly,
>> but it now seems to be that only every Nth video frame is passed
>> to the video pipe, where N is somewhere between 3 and 10. I don't
>> mean it varies between 3 and 10. It is a constant factor. It's just
>> that I don't know what the factor is. (I've just realised that I could
>> find out by changing the frame rate I reencode at until I get the
>> right speed - I can do that if you like). The effect I see is
>> the audio is fine, and the video looks to be on fast forward. It's
>> not that ffmpeg is messing up the mux, because I can do a video-only
>> encode and I still see the same problem (and not if I remove --passthrough).
>
> Probably because timestamp calculations is based on the size of the
> decoded audio (in PCM). We know the audio rate; we now the sample and
> frame size so to calculate the timestamps and length of the audio data
> we simply divide the length of the decoded audio by the frame size and
> framerate...
>
> With raw audio, that calculation will obviously return a wrong result.

Raw meaning undecoded - yeah I wondered if that might be it, although
when I thought it through, it seemed that that would give repeated
frames rather than missed frames: compressed data would be smaller, so
the timestamp calculation would come out too small, so it would seem
like an earlier frame... ah no, scrap that... so audio time would be
slowed, which would make it seem like the video frames were being
produced too fast, and they'd need decimating. Yeah, sounds right on
second attempt. :-)

> I guess, I will have to decode the audio completely as well as passing
> the raw compressed audio ; in order to calculate the timestamps
> properly.

I found this which might help: 
http://www.rfc-editor.org/rfc/rfc4184.txt. Suggests that - for a given 
sample rate - ac3 frames
have a fixed duration (top of Page 3). Just thought spotting frames
might be easier than a full decode.

> Glad it's working that well already though ; it was completely untested ...

Yeah. Seems really close to me.

Paul.