When playing unreliable H264 streams with FFPlay, I seem to get
core-dumps randomly every few hours. The exact location is usually the
second instruction of "pred8x8_top_dc_8_mmxext" in "h264_intrapred.asm",
where it dereferences "dest_cr" after subtracting "uvlinesize" from it,
as called from
Mark Stevans writes:
> When playing unreliable H264 streams with FFPlay, I
> seem to get core-dumps randomly every few hours.
This sounds important, please provide the necessary
information as explained on
http://ffmpeg.org/bugreports.html
A sample would be useful (the size limitation
menti
Carl Eugen Hoyos writes:
> Mark Stevans ...> writes:
>
> > When playing unreliable H264 streams with FFPlay, I
> > seem to get core-dumps randomly every few hours.
>
> This sounds important, please provide the necessary
> information as explained on
> http://ffmpeg.org/bugreports.html
I ap
You explained -- just not strongly enough to make me understand.
It takes hours of testing to generate a stack trace, but I wrote down
the most import part -- the last two frames. And it's very difficult to
get a clip for reproduction, as this is a live stream running for hours.
To be honest
Mark Stevans writes:
> It takes hours of testing to generate a stack trace
I am not sure I understand: The additional effort
should be far below five minutes, could you
elaborate?
> And it's very difficult to get a clip for reproduction,
> as this is a live stream running for hours.
rtmpdum
On 6/21/2013 1:36 AM, Carl Eugen Hoyos wrote:
Mark Stevans writes:
It takes hours of testing to generate a stack trace
I am not sure I understand: The additional effort
should be far below five minutes, could you
elaborate?
Ah, I wasn't clear yet again: when I said "core-dump", I don't mea
Mark Stevans writes:
> when I said "core-dump", I don't mean an actual
> core-dump on disk. I'm running under Windows 7
> here, debugging with WinDbg
gdb works fine on Windows (7), it would also allow
to produce a useful backtrace (and disassembly and
register content) for a recorded st
Mark Stevans writes:
> Frankly, I don't understand how patches could be
> ignored on TRAC, yet observed in "ffmpeg-devel".
I was just describing what experience tells me.
> But I will send my patch there
It appears that I was unclear again, sorry about that!
Bug reports are not welcome on ffm
On 6/21/13, Carl Eugen Hoyos wrote:
> Mark Stevans writes:
>
>> Frankly, I don't understand how patches could be
>> ignored on TRAC, yet observed in "ffmpeg-devel".
>
> I was just describing what experience tells me.
>
>> But I will send my patch there
>
> It appears that I was unclear again, sor
Paul B Mahol writes:
> Are you enjoying yourself?
You mean compared to you when you (intentionally!)
commit other people's patches?
Carl Eugen
___
Libav-user mailing list
Libav-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/libav-user
On 6/21/2013 2:39 AM, Carl Eugen Hoyos wrote:
Mark Stevans writes:
when I said "core-dump", I don't mean an actual
core-dump on disk. I'm running under Windows 7
here, debugging with WinDbg
gdb works fine on Windows (7), it would also allow
to produce a useful backtrace (and disassembly
Mark Stevans writes:
> > gdb works fine on Windows (7)
>
> I spent days trying to debug earlier bugs with
> Windows GDB, but couldn't get decent stack
> traces -- I tried every possible debugging
> flag and symbol format to no avail.
That surprises me:
I am regularly using gdb to debug on Wi
On 6/21/13, Carl Eugen Hoyos wrote:
> Paul B Mahol writes:
>
>> Are you enjoying yourself?
>
> You mean compared to you when you (intentionally!)
> commit other people's patches?
What other people's patches?
___
Libav-user mailing list
Libav-user@ffmpe
13 matches
Mail list logo
