[FFmpeg-user] Combining -muxrate and -copyts results in unexpected high bitrates

[Roman Huy-Prech]

I just realized, that not using -copyts but setting an -output_ts_offset 
in combination with -muxrate leads to the same result - the higher the 
ts_offset, the bigger the file gets, so it seems the padding of the 
-muxrate applies to the time before the offset too. Is this intentional 
or a bug?

On 16.10.19 14:10, Roman Huy-Prech wrote:
> I want to transcode individual mpegts (h264/aac) chunks, and two 
> things are very important:
> 1) A constant, predictable output bitrate
> 2) Keeping the original pts information.
>
> For this minimal example I'm using this public accessible mpegts chunk 
> and the least amount of arguments needed to reproduce:
> https://bitdash-a.akamaihd.net/content/sintel/hls/1500kbit/seq-38.ts
> Let's say I want 300k output bitrate:
>
> Original Chunk:
> Duration: 00:00:02.00, start: 76.083333, bitrate: 919 kb/s
>
> Using -copyts I can copy over the timings. Good. But I want 300k.
> ffmpeg -i seq-38.ts -vf scale=320:240 -f mpegts -muxdelay 0 -copyts 
> -vcodec libx264 -crf 19 -y seq-38-copyts.ts && ffprobe seq-38-copyts.ts
> Duration: 00:00:02.00, start: 76.083333, bitrate: 245 kb/s
>
> Using -muxrate 300k gives me 296k - Good enough. But this is without 
> -copyts.
> ffmpeg -i seq-38.ts -vf scale=320:240 -f mpegts -muxdelay 0 -vcodec 
> libx264 -crf 19 -y -muxrate 300k seq-38-copyts.ts && ffprobe 
> seq-38-copyts.ts
> Duration: 00:00:02.00, start: 0.083333, bitrate: 296 kb/s
>
> Now I'm combining the two, I have the correct start time again, but 
> wtf? 11696 kb/s?
> ffmpeg -i seq-38.ts -vf scale=320:240 -f mpegts -muxdelay 0 -copyts 
> -vcodec libx264 -crf 19 -y -muxrate 300k seq-38-copyts.ts && ffprobe 
> seq-38-copyts.ts
> Duration: 00:00:02.00, start: 76.083333, bitrate: 11696 kb/s
>
>
> What is happening here, and how can I achieve having the correct 
> timing information while having a very CBR stream?
> I really want to avoid ffprobing the chunk first and also avoid 2-pass 
> encoding, as this is for very low latency, on-demand transcoding.
>
> Thanks for any suggestions!
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".

-- 
Roman Huy-Prech
rossi at diehalbstarken.at
t. +43 650 56 333 46

www.diehalbstarken.at