On 03/06/2016 01:29 PM, Ronald S. Bultje wrote:
Hi Mats,
On Sun, Mar 6, 2016 at 6:51 AM, Mats Peterson <
matsp888-at-yahoo....@ffmpeg.org> wrote:
On 03/06/2016 12:09 PM, Michael Niedermayer wrote:
Once again, why are these tests unneeded?
You shouldn't send the same message 5x within 2 seconds. Please be patient.
Why are they unneeded? Imagine this situation:
----
int a;
if (condition)
a = create_a();
[..]
if (condition)
do_something_with_a(a);
----
versus:
----
int a = create_a();
[..]
if (condition)
do_something_with_a(a);
----
Oddly, both codes do exactly the same thing, assuming they don't change
global state. In this case, avio_tell() shouldn't change global state, that
is, we're assuming that it will not cause bitstream corruption simply
because it's unseekable, which is a fair assumption.
On the positive side, with that assumption, code fragment #2 is much
simpler than #1, which is why the patch is net positive.
Ronald
_______________________________________________
ffmpeg-devel mailing list
Well, that part I understand. It's for simplification purposes.
By the way, I just noticed that avio_tell() (and avio_seek() will work
on stdout as well. That's the part I *don't* understand: How can they
work on an "officially" unseekable stream like stdout, when ftell() and
lseek() won't? Is it due to the buffering in FFmpeg? And where's the
limit where a normally "unseekable stream" like stdout is no longer
seekable with avio_seek()? Hope you understand what I mean.
Mats
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
