On Wed, 28 Aug 2019, Marton Balint wrote:
On Wed, 28 Aug 2019, Andreas Håkon wrote:
Hi Marton,
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, 27 de August de 2019 23:33, Marton Balint <c...@passwd.hu>
wrote:
> Please, note that the main problem at time with the mpegts muxer is that
all PES packets are
> written sequentially. And this generates a lot of problems when the
video PES packets are large,
> or when the audio packets aren't flushed at regular intervals. If you
prefer to improve the
> current sequential mode before you do anything with the interleaved
mode, then I give this
> suggestion: Use a PES SIZE INTERVAL for audio packets instead of
calculating a TIME DELAY. With
> CBR audio steams, every audio PES packet has the same payload size.
I am not sure what you mean when you say PES size interval, but if you are
referring to the size of the PES packet - that is exactly what we had in
the very beginning, and it was not sufficent because for low bitrate
streams when combining small audio packets to a PES packet it took too
long time, and in order to generate a proper TS we have to make sure that
we don't delay the audio packets too much, becuase if we do, then it will
arrive at the destination later then the PCR which makes presentation
impossible.
The problem is that you're thinking of using the same pes_size for all
audio packets!
For each audio stream you need to calculate the correct pes_size.
max_pes_size = max_audio_delay * audio_bitrate
it is the same thing for CBR, you calculate one from the other.
And the value is based on the bitrate. So for CBR audio streams the value
is
fixed, and you only need to recalculate it for VBR audio streams.
Please, try to add some "pes_top_size" member at stream level, and use it
for
audio streams. You can calculate the value when you know the bitrate, and
after that a simple "if ts_st->payload >= ts_st->pes_top_size" will be
sufficient
to trigger the dispatch of the PES packet.
I don't see how calclating a max_pes_size is superior. It _only_ works for
CBR, plus you don't really know the audio bitrate, you'd have to guess it
from some frame sample count and audio packet size.
What is the disadvantage of always using a timestamp based contraint
instead of a sized based? A timestamp based one works for both CBR and
VBR, and you don't have to recalculate anything based on some bitrate
guessing.
Applied this as well.
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".