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......
- Michael On Thu, 2013-01-03 at 16:16 +0000, Carl Eugen Hoyos wrote: > Michael R. Hines <michael@...> 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 > standards. > 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 > defined. > > Carl Eugen > > _______________________________________________ > Libav-user mailing list > [email protected] > http://ffmpeg.org/mailman/listinfo/libav-user
_______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
