Στις Παρ, 3 Μαΐ 2019 στις 6:39 μ.μ., ο/η Michael Niedermayer
έγραψε:
>
> This allows handling more than 26.5h of mpeg* input
>
> Fixes: Ticket 7876
>
I confirm it fixes the case described in the ticket. Will now test it
in realtime environment, so it will take 26,5 hours to report back.
Thank you
Στις Παρ, 3 Μαΐ 2019 στις 11:36 π.μ., ο/η Michael Niedermayer
έγραψε:
>
> this will break timestamp handling
> not sure what you are trying to do exactly but the way its done is wrong.
> There is alot of code that depends on the timestamps from the demuxer
> not being mangled like this.
>
> also i
OK, here it is again, attached.
Στις Πέμ, 2 Μαΐ 2019 στις 9:56 μ.μ., ο/η Carl Eugen Hoyos
έγραψε:
>
> Am Do., 2. Mai 2019 um 20:52 Uhr schrieb Panagiotis Malakoudis
> :
> >
> > > On Thu, May 02, 2019 at 08:13:10PM +0300, Panagiotis Malakoudis wrote:
>
> > > &
> On Thu, May 02, 2019 at 08:13:10PM +0300, Panagiotis Malakoudis wrote:
> > When outputing to mpegts format, using -copyts option makes program
> > fail after the oveflow of mpegts PCR happens at around 26 hours and 30
> > minutes. When not using -copyts, only a warning is r
When outputing to mpegts format, using -copyts option makes program
fail after the oveflow of mpegts PCR happens at around 26 hours and 30
minutes. When not using -copyts, only a warning is reported.
In order to reproduce the issue, you first have to create a 27 hour
mpegts video.
I have described
