Combining -muxrate and -copyts results in unexpected high bitrates

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Combining -muxrate and -copyts results in unexpected high bitrates

Roman Huy-Prech
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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: 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
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".

--
Roman Huy-Prech
[hidden email]
t. +43 650 56 333 46

www.diehalbstarken.at

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Combining -muxrate and -copyts results in unexpected high bitrates

Moritz Barsnick
In reply to this post by Roman Huy-Prech
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.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

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.083333, 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Combining -muxrate and -copyts results in unexpected high bitrates

Roman Huy-Prech
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.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
> 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.083333, 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
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Combining -muxrate and -copyts results in unexpected high bitrates

Moritz Barsnick
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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".