[FFmpeg-devel] [PATCH 1/2] Modified to generate PAT/PMT on every video keyframe. This is so that TS fragments produced by http://code.google.com/p/httpsegmenter/ would be compatible with JW Player.
michaelni at gmx.at
Fri Feb 10 21:13:53 CET 2012
On Fri, Feb 10, 2012 at 01:03:02PM -0700, Pavel Koshevoy wrote:
> On 2/10/2012 12:29 PM, Reimar Döffinger wrote:
> >On Fri, Feb 10, 2012 at 12:06:36PM -0700, pkoshevoy at gmail.com wrote:
> >I don't know enough about TS to comment much, except that this
> >is possibly a bit crazy for the intra-only use case.
> Yes, this would add some overhead in intra-only case, but that would
> not break compatibility. When intra-only is used does anyone really
> care about file size? It's going to be bloated anyway. However, if
> someone can suggest to me a way to detect intra-only stream I can
> change the patch. I am still very new to ffmpeg code base, I don't
> know everything that is available.
Simply testing for last=nonkey, current=key should be best. It would
even work when intra only and mixed are concatenated
> One thing that I would like to know -- does AV_PKT_FLAG_KEY refer to
> I frames or IDR frames? I am only interested in IDR frames...
> httpsegmenter starts a new TS fragment file when it sees
> AV_PKT_FLAG_KEY, it would be unfortunate if this was not an IDR
the definition of AV_PKT_FLAG_KEY is pretty much a place from where
one can start decoding.
In streams without IDR frames and without I frames its surely possibly
to have P frames marked as AV_PKT_FLAG_KEY. See SEI recovery frame
count in the specs for some more details on how one starts to decode
In normal streams assuming AV_PKT_FLAG_KEY == IDR may work
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel