[FFmpeg-devel] [PATCH 2/2] lavd/lavfi: raise probesize if necessary.

[Nicolas George]

Le tridi 3 floréal, an CCXX, Stefano Sabatini a écrit :
> This is semantically problematic. Suppose the user sets the default
> value explicitely and by chance it is the same as the default value,
> then she may *want* to keep that value.

I was aware of that, and I tried other solutions before that, but they soon
became too complicated.

My reasoning to go on with it is that the exact value of probesize does not
matter much usually: if the user wants to stay at the default, they can
write "-probesize 4999999" or "-probesize 5000001", the difference with the
default will be negligible.

> What could go wrong with a too big value?

Probably nothing.

> I suggest to add an option - you may call it -auto_probesize or
> whatever you want to call it - so that it is still possible to set the
> probesize value explicitely, when the option is on the heuristic
> presented in this patch is applied (you can set it by default if you
> think it would be useful to prevent the issue).

I believe it starts being too complex for the user.

I see two alternative solutions:

* Set the default value of probesize to -1, and have lavf test:
  if (probesize == -1) probesize = 5000000;
  after read_header. Unfortunately, probesize is used in several places
  before read_header, that makes the code more complicated.

* Add a field to AVOption: "int *is_default": if it is not NULL,
  av_opt_set_defaults sets it to 1 while av_opt_set sets it to 0.

I just thought of another option:

* Create a new option -infoprobesize, with default value 0 meaning "use the
  same value as -probesize or a format-specific value".

> BTW why is lavfi special in this regard? Why the issue is not required
> e.g. with the video4linux device?

To trigger the problem, you need a format where:

- very large frames (probably rawvideo) are supported;
- the timebase is very small (so that tb_unreliable returns true);
- the header does not set the frame rate reliably.

I did not manage to find another format that meets these conditions, but if
there is, the workaround should be shared.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120421/16320a38/attachment.asc>