Re: [FFmpeg-user] Combining -muxrate and -copyts results in unexpected high bitrates
On Thu, Oct 17, 2019 at 10:57:43 +0200, Roman Huy-Prech wrote: > I opened https://trac.ffmpeg.org/ticket/8297 > > Sorry for not posting the complete output here, I thought that was > something for the bugtracker (I did it there =) ) Perfect, thank you! Cheers, Moritz ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Combining -muxrate and -copyts results in unexpected high bitrates
I opened https://trac.ffmpeg.org/ticket/8297 Sorry for not posting the complete output here, I thought that was something for the bugtracker (I did it there =) ) Cheers, Roman On 16.10.19 16:23, Moritz Barsnick wrote: On Wed, Oct 16, 2019 at 14:10:58 +0200, Roman Huy-Prech wrote: and the least amount of arguments needed to reproduce: https://bitdash-a.akamaihd.net/content/sintel/hls/1500kbit/seq-38.ts Incorrect URL, this is the correct one: https://bitdash-a.akamaihd.net/content/sintel/hls/video/1500kbit/seq-38.ts Original Chunk: Duration: 00:00:02.00, start: 76.08, 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.08, bitrate: 245 kb/s You should always provide us with the command and its complete, uncut console output. In this case, thanks to the sample (almost), we can reproduce, but it's nicer to see *your* actual results, not our own. 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.08, bitrate: 11696 kb/s Apparently, ffmpeg is taking the additional 78 seconds offset from the copyts into consideration: frame= 48 fps= 15 q=-1.0 Lsize=2856kB time=00:01:17.95 bitrate= 300.1kbits/s speed=24.3x video:54kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 5149.501953% (This is what we ask for the complete output for - we can point out where iut shows you the issue!) Note that ffmpeg thinks it encoded 1:17.95 (not 0:02.00) at 300.1kbits/s. (See all that muxing overhead!) Looking at my resulting file size, that's even quite precisely correct: (no. of bytes in filesize, times bits in a byte, divided by assumed length in seconds, is the bit rate:) $ calc "2924340 / 77.95 * 8" ~300124.69531751122514432328 Except that the resulting video isn't actually 77.95 seconds long. ;-) Therefore, the resulting overall bit rate is wrong. So I believe copyts is confusing the muxrate calculation, pretty much like the guess in your second e-mail. I consider it a bug. (BTW, there do exist other external tools to pad an MPEG-TS to a CBR. ffmpeg's MPEG-TS does have some deficits, but this isn't supposed to be one of them.) Cheers, Moritz ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Combining -muxrate and -copyts results in unexpected high bitrates
On Wed, Oct 16, 2019 at 14:10:58 +0200, Roman Huy-Prech wrote: > and the least amount of arguments needed to reproduce: > https://bitdash-a.akamaihd.net/content/sintel/hls/1500kbit/seq-38.ts Incorrect URL, this is the correct one: https://bitdash-a.akamaihd.net/content/sintel/hls/video/1500kbit/seq-38.ts > Original Chunk: > Duration: 00:00:02.00, start: 76.08, 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.08, bitrate: 245 kb/s You should always provide us with the command and its complete, uncut console output. In this case, thanks to the sample (almost), we can reproduce, but it's nicer to see *your* actual results, not our own. > 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.08, bitrate: 11696 kb/s Apparently, ffmpeg is taking the additional 78 seconds offset from the copyts into consideration: > frame= 48 fps= 15 q=-1.0 Lsize=2856kB time=00:01:17.95 bitrate= > 300.1kbits/s speed=24.3x > video:54kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing > overhead: 5149.501953% (This is what we ask for the complete output for - we can point out where iut shows you the issue!) Note that ffmpeg thinks it encoded 1:17.95 (not 0:02.00) at 300.1kbits/s. (See all that muxing overhead!) Looking at my resulting file size, that's even quite precisely correct: (no. of bytes in filesize, times bits in a byte, divided by assumed length in seconds, is the bit rate:) $ calc "2924340 / 77.95 * 8" ~300124.69531751122514432328 Except that the resulting video isn't actually 77.95 seconds long. ;-) Therefore, the resulting overall bit rate is wrong. So I believe copyts is confusing the muxrate calculation, pretty much like the guess in your second e-mail. I consider it a bug. (BTW, there do exist other external tools to pad an MPEG-TS to a CBR. ffmpeg's MPEG-TS does have some deficits, but this isn't supposed to be one of them.) Cheers, Moritz ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Combining -muxrate and -copyts results in unexpected high bitrates
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.08, 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.08, 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.08, 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.08, 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@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". -- Roman Huy-Prech ro...@diehalbstarken.at t. +43 650 56 333 46 www.diehalbstarken.at ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
