[Libav-user] muxer ignoring my PTS audio values
Michael R. Hines
michael at hinespot.com
Thu Jan 3 17:24:11 CET 2013
Thanks for the reply.
So, then a more accurate observation is that it is not advised to split
or merge multimedia content
using "raw" containers - as they may or may not support timestamps
properly when the
media is multiplexed......
On Thu, 2013-01-03 at 16:16 +0000, Carl Eugen Hoyos wrote:
> Michael R. Hines <michael at ...> writes:
> > the problem was that I was not using a *actual*
> > container to encapsulate my audio/video streams.
> > For example, if you make a call like this, for example:
> > avformat_alloc_output_context2(&ctx->outAudioFormatCtx, NULL, "ac3", NULL)
> > or avformat_alloc_output_context2(&ctx->outAudioFormatCtx, NULL, "h264", NULL)
> Please understand that both "ac3" and "h264" are "actual"
> containers in the sense that they are defined by public
> You can test those containers with ffmpeg (the application):
> $ ffmpeg -i input -f ac3 out1
> $ ffmpeg -i input -f h264 out2
> (The second example needs a ffmpeg executable with x264 support.)
> Both output files should decode fine with FFmpeg (and out2 for
> example with the H264 reference decoder).
> Both "ac3" and "h264" are of course raw containers, but that
> does not make them less "actual" imo (especially given that
> both are defined in "actual" codec standards).
> Please note that I suspect the h264 format does support
> timestamps, FFmpeg support for these timestamps is
> unfortunately limited, several tickets are open.
> I am not sure how timestamps for encoded audio would help,
> afaik when decoding ac3 streams the decoding speed is
> Carl Eugen
> Libav-user mailing list
> Libav-user at ffmpeg.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libav-user