On Sun, Jun 12, 2016 at 02:59:14PM -0400, DeHackEd wrote:
> On 06/12/2016 02:31 PM, Carl Eugen Hoyos wrote:
> > DeHackEd dehacked.net> writes:
> >
> >> The effects vary a bit. One guy in IRC basically had ffmpeg
> >> crash for him every 26.5 hours when he was saving to HLS
> >
> > And when I as
DeHackEd dehacked.net> writes:
> $ ffmpeg -i longvideo.ts -c copy -f mpegts -copyts output.ts
Why are you using -copyts and what is wrong with the output file?
If the crash report is really unreproducible (which seems
inexplicable to me), then at least backtrace, disassembly
and register dump
On 06/12/2016 02:31 PM, Carl Eugen Hoyos wrote:
> DeHackEd dehacked.net> writes:
>
>> The effects vary a bit. One guy in IRC basically had ffmpeg
>> crash for him every 26.5 hours when he was saving to HLS
>
> And when I asked him how I can reproduce this issue he
> unfortunately couldn't answ
DeHackEd dehacked.net> writes:
> The effects vary a bit. One guy in IRC basically had ffmpeg
> crash for him every 26.5 hours when he was saving to HLS
And when I asked him how I can reproduce this issue he
unfortunately couldn't answer;-(
Carl Eugen
_
On 06/12/2016 01:57 PM, Carl Eugen Hoyos wrote:
> DeHackEd dehacked.net> writes:
>
>>> So the bug is that the file gets longer when read with FFmpeg?
>>
>> Heh... that's my fault for copy/pasting from the wrong invocation.
>> I have two test cases, one generated from the above testsrc and
>> on
DeHackEd dehacked.net> writes:
> > So the bug is that the file gets longer when read with FFmpeg?
>
> Heh... that's my fault for copy/pasting from the wrong invocation.
> I have two test cases, one generated from the above testsrc and
> one that actually consists of a 28+ hour recording from a
On 06/12/2016 12:06 PM, Carl Eugen Hoyos wrote:
> DeHackEd dehacked.net> writes:
>
>> $ ffmpeg -r 5 -f lavfi -i testsrc -c:v libx264 -profile:v veryfast
>> -t 97000 bigfile.ts
>
>> $ ffmpeg -i bigfile.ts -c:v copy -f null /dev/null
>
>> frame=487718 fps=228472 q=-1.0 Lsize=N/A time=27:05:43.00
DeHackEd dehacked.net> writes:
> $ ffmpeg -r 5 -f lavfi -i testsrc -c:v libx264 -profile:v veryfast
> -t 97000 bigfile.ts
> $ ffmpeg -i bigfile.ts -c:v copy -f null /dev/null
> frame=487718 fps=228472 q=-1.0 Lsize=N/A time=27:05:43.00
So the bug is that the file gets longer when read with FFm
On Sun, Jun 12, 2016 at 08:31:45AM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Jun 12, 2016 at 8:23 AM, Michael Niedermayer > wrote:
>
> > On Sat, Jun 11, 2016 at 06:55:32PM -0400, DeHackEd wrote:
> > > Presently the mpegts demuxer passes the timestamps from received packets
> > directly to
On 06/12/2016 08:23 AM, Michael Niedermayer wrote:
> On Sat, Jun 11, 2016 at 06:55:32PM -0400, DeHackEd wrote:
>> Presently the mpegts demuxer passes the timestamps from received packets
>> directly to the output AVPackets. 2^33 / 9
>> seconds is about 26.5 hours at which point applications st
Hi,
On Sun, Jun 12, 2016 at 8:23 AM, Michael Niedermayer wrote:
> On Sat, Jun 11, 2016 at 06:55:32PM -0400, DeHackEd wrote:
> > Presently the mpegts demuxer passes the timestamps from received packets
> directly to the output AVPackets. 2^33 / 9
> > seconds is about 26.5 hours at which point
On Sat, Jun 11, 2016 at 06:55:32PM -0400, DeHackEd wrote:
> Presently the mpegts demuxer passes the timestamps from received packets
> directly to the output AVPackets. 2^33 / 9
> seconds is about 26.5 hours at which point applications start having a fit,
> and that's assuming timestamps begi
On 06/12/2016 04:07 AM, Carl Eugen Hoyos wrote:
> DeHackEd dehacked.net> writes:
>
>> So here's a first revision of a patch to fix that issue.
>
> How can I reproduce the issue?
1) Produce a very long video, around 27 hours long or so, in mpegts format
$ ffmpeg -r 5 -f lavfi -i testsrc -c:v li
DeHackEd dehacked.net> writes:
> So here's a first revision of a patch to fix that issue.
How can I reproduce the issue?
Imo, the reindentation makes your patch very difficult to read.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 06/11/2016 08:19 PM, Marton Balint wrote:
>
> On Sat, 11 Jun 2016, DeHackEd wrote:
>
>> Presently the mpegts demuxer passes the timestamps from received packets
>> directly to the output AVPackets. 2^33 / 9
>> seconds is about 26.5 hours at which point applications start having a fit,
>>
On Sat, 11 Jun 2016, DeHackEd wrote:
Presently the mpegts demuxer passes the timestamps from received packets
directly to the output AVPackets. 2^33 / 9
seconds is about 26.5 hours at which point applications start having a fit, and
that's assuming timestamps begin at time 0.
So here's a
Presently the mpegts demuxer passes the timestamps from received packets
directly to the output AVPackets. 2^33 / 9
seconds is about 26.5 hours at which point applications start having a fit, and
that's assuming timestamps begin at time 0.
So here's a first revision of a patch to fix that is
17 matches
Mail list logo