[vlc-devel] [vlc-commits] codec: don't drop discontinue blocks

[Ilkka Ollakka]

Hi all,

On Thu, Oct 15, 2015 at 02:11:54AM +0300, Ilkka Ollakka wrote:
> On Wed, Oct 14, 2015 at 10:54:27AM +0300, Rémi Denis-Courmont wrote:
> > Le 2015-10-14 00:12, Ilkka Ollakka a écrit :

> > >So is it that discontinuity flag is some old relic that shouldn't be
> > >even around anymore or was it meant to be used for something different
> > >all together than signal that there could be packets missing between
> > >this and previous block?

> > I think it's the former. Decoder can choose what to do with discontinuous
> > data. Especially for audio, I think we should just reset the PTS (or
> > interpolate it), not flush.

> I think you are right, we should just reset pts in those cases and let
> decoder do resync or whatever it seems fit without flushing. I can
> rework those patches to add patch that remove those flushing cases and
> I'll send them to list most likely closer to the weekend for another
> round.

I checked patches and actually codec/packetizer wise they worked already
as agreed, so no flushing on discontinuity but only resetting timestamp.

I just commited those in too hastly without waiting possible feedback
and that was the main cause of this revert hassle. Sorry about that.

I think those ts-demuxer changes and comment change in vlc_block about
what discontinuity means are against this understanding that
discontinuity is just notify that there are blocks lost between previous
and this one. So those should be remade (including the qt4 string
change). So ts discontinuity is handled with pcr_reset and not placing
flag_discontinuity in block.

I would propose following:
-----
remake/revert of following (block_discontinuity comments and ts-demux):
- de4be0a4505564a5f758f06edd74f49498107f6e (vlc_block comment)
- fa9af46da2190e05398d8e1e3e932312c24fd73f (ts demuxer flag passing)
- d700966ec0ab7f98ae4308cfcffe5c4d7ea66718 (qt4 string change)

Reapply following that I reverted by Remis request:
- 48a867c768aeddcd2756c49960eaa2eb42629fbe 
- 5e36cb2c1485830cf152c05767301a6732b08297 

-----

I think for me biggest issues is those reverts, if I just revert those I
think blame/author of those lines fall to me and not rightfully to
jpsaman on 48a867c768aeddcd2756c49960eaa2eb42629fbe. I don't know how
that could be nicely handled?

Any futher opinions about this approach/proposal to proceed?

-- 
Ilkka Ollakka
You know it's going to be a bad day when you want to put on the clothes
you wore home from the party and there aren't any.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20151017/bb8cb8d9/attachment.sig>