<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2">
</HEAD>
<BODY>
So, for the uneducated (like myself), the problem was that I was not using a *actual* container to encapsulate my audio/video streams.<BR>
<BR>
For example, if you make a call like this, for example:<BR>
<BR>
avformat_alloc_output_context2(&ctx->outAudioFormatCtx, NULL, "ac3", NULL)<BR>
<BR>
or avformat_alloc_output_context2(&ctx->outAudioFormatCtx, NULL, "h264", NULL)<BR>
<BR>
.... the libraries happily go ahead and succeed with the understanding that:<BR>
<BR>
"Oh, you don't want to use a container? <BR>
No problem - we'll just dump your packets to a file without any timestamps".<BR>
<BR>
This is easily fixed by using a TS container like this:<BR>
<BR>
avformat_alloc_output_context2(&ctx->outAudioFormatCtx, NULL, "mpegts", NULL)<BR>
<BR>
Followed by the approriate libav functions to open the *exact* codecs that you wanted.<BR>
<BR>
Ideally, the libraries should at least print a message that says:<BR>
<BR>
"Warning! Your AVFormatContext does not use a container. Be warned!"<BR>
<BR>
Or something threatening like that........<BR>
<BR>
Is that an accurate observation?<BR>
<BR>
- Michael<BR>
<BR>
On Mon, 2012-12-31 at 21:36 -0500, Michael R. Hines wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi,
Following a few previous posts on libav-user, I've been trying to get
my audio and video synchronized using the dranger tutorial.
I'm transcoding (from mpeg2/ac3 to h264/ac3) to make a Blu-ray disc.
So, I scrounged up some code from the tutorial and this mailing list
and everything seems to be fine, except for the audio sync.
In my case, I'm just copying the audio packets (not decoding them).
Similar to this post:
<A HREF="https://lists.libav.org/pipermail/libav-user/2010-January/004170.html">https://lists.libav.org/pipermail/libav-user/2010-January/004170.html</A>
I noticed the the audio packets are always off from the video by a
constant factor when I try to play the video.
So, naturally, I tried a binary search by "tweaking" the PTS value
by fixed offsets.
But when I validate the PTS values with "ffprobe -show_packets", the
muxer did not use the PTS values that I choose.
Instead, the PTS values start from zero and continue up rather than
the values I chose.
The muxer did not print any errors - it wrote the "copied"
audio packets just fine - so I assumed my chosen PTS values would
have been written to.
Playing the audio on my desktop also works fine - it's just that
it has the wrong PTS values.
Is there something I need to do to "make" the muxer respect the
values I've chosen?
Thanks!
- Michael
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>