[Libav-user] Fw: strange H264 audio sync behavior

[Kalileo]

On Jul 17, 2014, at 17:14 , Marco Sieber wrote:

> >I wrote a Transcoder it works fine so far, in generell its X Container/Format to MP4/H264.
> >We have a 20min File (5GB) its a QuickTime Movie (DNxHD36) the MP4 Output works fine with VLC (no sync issue).
> >But if i open it with Quicktime Player (v 10.x) i get a async audio after 5min, if i using the Scrubbing Bar from the Player it resync and >after 5min playtime it gets out of sync again.
>  
> Hi me again,
> 
> i now test a little bit with the transcoder.c example from ffmpeg 2.x and i changed it a little bit so that it transcodes to h264/aac.
> and there i get the same "out of sync" issues. (ofc im only do trial and error)

Since ffmpeg (the program) does not show the problem, also not when transcoding to h264/aac, you might have to check your changes. May be start that again and test in smaller steps until you see what change caused QT to get out of sync.

> Is it possible that maybe libfaac has some trouble, i'm not 100% sure but i believe i compiled ffmpeg libs with libfaac and read somewhere there might some problems with it. Someone knows anything about this? Is it possible in general?

So far I have not seen libfaac cause such issues, nor any other of the aac encoders which can get used with ffmpeg. 

> Are there some analytic Tools?
> Is it possible to see which value QT decodes/reads... so that i gain some data?
> 
> On the other hand... if i google about "quicktime sound out of sync" i get some entries but not ffmpeg related... hmm... i hate these digging and not knowing whats going on.
> 
> This is what i use for encoder context in your transcoder example, just the basis:
> 
> video:
> enc_ctx->codec_id = AV_CODEC_ID_H264;
> enc_ctx->sample_aspect_ratio = dec_ctx->sample_aspect_ratio;
> enc_ctx->pix_fmt = AV_PIX_FMT_YUV420P;
> enc_ctx->level = 31;
> enc_ctx->profile = FF_PROFILE_H264_BASELINE;
> AVDictionary * codec_options( 0 );
> av_dict_set( &codec_options, "preset", "slow", 0 );
> av_dict_set(&codec_options, "vprofile", "baseline", 0);
> 
> audio:
> enc_ctx->profile = FF_PROFILE_AAC_LOW;
> enc_ctx->codec_id = AV_CODEC_ID_AAC;
> enc_ctx->sample_rate = 48000;
> enc_ctx->channels = 2;
> enc_ctx->channel_layout = AV_CH_LAYOUT_STEREO;
> AVDictionary * codec_options( 0 );
> av_dict_set(&codec_options, "strict", "experimental", 0);

Are you manipulating the timebase and the DTS / PTS from the input before you give it to the encoding / muxing functions?

Are you passing the proposed DTS / PTS from the ffmpeg encoding functions to the muxer, or are you manipulating them in between?

In my experience it works fine to use the DTS / PTS values as the encoder functions (audio and video) propose, and that with any player, custom or VLC or QT.

So far I have _not_ seen them going out of sync unless there are problems in the input, such as an input stream suffering from packet loss, and therefore having gaps in the input streams.

You seem to have input with correct timestamps, let me propose to use them in your input, unchanged, and then for the muxer use what the ffmpeg encoding functions propose.

if you have QT going out of sync steadily that hints to me as if the timebase might be set wrong, or you might do another manipulation with the timestamps.

You might also have different settings in the encoded data and in the container, and VLC uses the correct one, while QT might use the one with the correct settings. (I have seen such a settings mismatch in some wowza generated streams.)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://ffmpeg.org/pipermail/libav-user/attachments/20140717/6a40f38a/attachment.html>