[FFmpeg-devel] [RFC] allow mpegts demuxer to reload streamsifservice disappears

Michael Niedermayer michaelni
Sun Aug 5 15:54:15 CEST 2007


Hi

On Tue, Jul 17, 2007 at 12:05:29AM +0100, M?ns Rullg?rd wrote:
> "elupus" <elupus at ecce.se> writes:
> 
> > "M?ns Rullg?rd" <mans at mansr.com> wrote in message 
> > news:yw1x4pk46lqh.fsf at thrashbarg.mansr.com...
> > "elupus" <elupus at ecce.se> writes:
> >
> > <snip>
> >
> >> Can you capture a stream where this change is needed?  I'd like to
> >> have a look.
> >>
> >
> > Obviously I wasn't smart enough to store the stream i originally had 
> > problems with (streaming directly from tuner card). But i expect the issue 
> > would crop up again if i swapped between a h264 encoded channel and one with 
> > standard mpeg2. The video would still come on the same PID. if now SVT-HD 
> > would start up where i live on dvb-t it would be easy to reproduce.
> >
> > I think in my case the issue came from an mp2 -> ac3 switch, but alas now i 
> > can't find any channel where it ends up that way. I think the tvserver sends 
> > the first audio stream it finds in the source on a fixed pid, then the 
> > second it finds on on one pid larger. same goes for video.
> >
> > so if on a channel change, the order things show up differs. ie it finds the 
> > ac3 stream first, instead of mp2 the pid's may swap. it correctly generates 
> > a new pat/pmt with a new version number on this change. so i don't think 
> > it's doing anything wrong.
> >
> > will let you know if I manage to capture such a stream again. might be easy 
> > to generate one by just concating two ts streams togheter which happen to 
> > use same pid for two different things.
> 
> In cases like you're talking about the program id would change, and
> the correct thing to do would be to report end of stream for all
> streams in the old program, and report the appearance of a new program
> with a new set of streams.
> 
> Unfortunately we have no means of doing this in lavf currently.

AVStream.duration could be used to indicate the end of stream together
with the last pts of the last AVPacket
this of course has the problem of running out of AVStreams but that problem
exists anyway unless we reuse AVStreams and that would cause a lot of
problems if the codec changes ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070805/790287e3/attachment.pgp>



More information about the ffmpeg-devel mailing list