[FFmpeg-devel] ts mux satus ?

Michael Niedermayer michaelni at gmx.at
Wed Apr 17 00:21:31 CEST 2013


On Tue, Apr 16, 2013 at 10:58:00PM +0100, Kieran Kunhya wrote:
> > Iam still quite curious what the problem with the API is and how a
> > different API could help?
> > That is when theres no volunteer to fix the incorrect interleaving
> > in the mpeg-ts muxer.
> > One surely can find a different way to submit packets, bytes, bits
> > or other to the muxer but ultimately the muxer has to interleave it
> > in line with the specification.
> > If a change to the API makes fixing the muxer simpler iam all for it.
> > but i disagere that theres a big issue in the API and a small issue
> > in the muxer. Actually iam still curious how a change to the API
> > can help at all? Could you elaborate on what issue the API has and
> > what alternative API would be in which way better?
> 
> So lets say I send packets A, B, C using the lavf api. How does the
> mux know when enough packets have arrived that it can start outputting
> data because the mux has to decide where to put packets even if they
> haven't arrived yet? You can start after B for example but it turns
> out that C should arrive before B, ad nauseam. Therefore you need to
> signal a "stop point" somehow.

There are multiple ways:
A. with the default per dts interleave the muxer is guranteed to
receive packets in dts order. So if the first packet in its que is
DTS=5 and the last DTS=10 then it knows there will be no packets with
DTS<10. This should work quite well for mpeg-ts i think if iam not
missing anything

B. If the per dts code is disabled or ignored or whatever then the
muxer could just wait until it has a packet in each stream. I suspect
that would suffice too but may need something for subtitles but then
it would be a great step forward already if our muxer would work
100% spec compliant without subs. 

Also mpeg-ts is flexible, theres more than one way to mux packets
spec compliantly. So if the arrival order at the muxers input changes
the file output thats not really a problem as long as the result is
spec compliant


> 
> In my mux the api mandates you provide all the frames in a given time
> period at once to avoid this. You provide all the frames you want to
> mux up to the video dts in one go. I'm not sure there's any other way
> to do it.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

DNS cache poisoning attacks, popular search engine, Google internet authority
dont be evil, please
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130417/416fdcfb/attachment.asc>


More information about the ffmpeg-devel mailing list