[FFmpeg-user] pcm_s16le (and flac) in TS fails

[Etienne Buira]

On Sat, Mar 24, 2012 at 07:32:52AM +0000, Carl Eugen Hoyos wrote:
> Etienne Buira <etienne.buira.lists <at> free.fr> writes:
> 
> > 1. ffmpeg -i source.something -ss 120 -t 120 -c:a pcm_s16le 
> > -c:v libx264 -preset ultrafast -qp 0 pcm_s16le.ts
> 
> Do you have any indication that pcm in mpeg-ts is supported 
> by any application?
> If yes, the developers will seriously consider adding decoding 
> (and possibly encoding) support to FFmpeg.
> 
> If FFmpeg supports encoding arbitrary codecs to (quite) 
> special-purpose containers (as opposed to for example avi) that 
> can certainly not be decoded by any other application, this 
> leads to guaranteed trouble.
> 
> If you really know what you are doing, you will find that it is 
> very simple to add support for arbitrary codecs to the mpeg-ts 
> encoder and decoder.
> 
> Carl Eugen

Hi Carl.

As said, I do not intent to use the (pcm,h264 q=0) in mpegts for longer
than temporary files.

My final goal is just to extract parts of some streams (aka ffmpeg -i
something_part1 -ss 10 t 120 tempout1 && ffmpeg -i something_part2 -ss
10 -t 120 tempout2) losslessly to concat them just after that and do a
lossy encode (aka ffmpeg -i 'concat://tempout1|tempout2' -crf 15 final).

I did this kind of thing with avi in the past, but it is not working
anymore at the concat step, so I tried with a container designed to be
concatenable (even if from what I understand, avi should be, as long as
index is not wished).

If you have a better idea of catable container/lossless video
codec/lossless audio codec that is usable with ffmpeg (and that offers
some compression, at least for video part), I'd buy it!
Ideally, the container also haves timestamps, in order to keep AV sync
even in case of slight corruption of the source.

Thanks for your answer.