[FFmpeg-devel] [PATCH 3/3] doc/muxers: Document range for mpegts periods

[Ganesh Ajjanagadde]

On Sat, Oct 17, 2015 at 12:33 PM, Michael Niedermayer
<michael at niedermayer.cc> wrote:
> On Fri, Oct 16, 2015 at 03:09:21PM -0400, Derek Buitenhuis wrote:
>> Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
>> ---
>>  doc/muxers.texi | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>> index 06483fa..cef04e1 100644
>> --- a/doc/muxers.texi
>> +++ b/doc/muxers.texi
>> @@ -802,9 +802,9 @@ Set a constant muxrate (default VBR).
>>  Override the default PCR retransmission time (default 20ms), ignored
>>  if variable muxrate is selected.
>>  @item pat_period @var{number}
>> -Maximal time in seconds between PAT/PMT tables.
>> +Maximal time in seconds between PAT/PMT tables. Max value is INT_MAX / 2 - 1.
>>  @item sdt_period @var{number}
>> -Maximal time in seconds between SDT tables.
>> +Maximal time in seconds between SDT tables. Max value is INT_MAX / 2 - 1.
>
> iam unsure about this, INT_MAX is theoretically platform specific and
> most non developers probably dont know its value
> that said, iam not against it at all, just feels like this cant be
> the best solution

Certainly not the best, but definitely better than the current - range
restrictions should be documented. Furthermore, INT_MAX is pretty well
known even for a first exposure to C, and in all likelihood someone
who reads the muxer docs is sharp/knows enough to do a quick google on
what INT_MAX is (after all, he was savvy enough to look at the docs).

Maybe one could in principle use configure to get the relevant actual
value and use that in the docs. That is pretty complex and should be
done IMHO only if there are more such type-width specific limits.
Furthermore, that has problems, if docs were obtained off a website
(website's config might be different from user's, etc). Given this, I
still favor the INT_MAX solution.

Also, on that note, it has already been noted that on all platforms we
have (currently) int is 32 bits. A lot more serious things will break
than the docs if the width of ints changes. That is another thing in
INT_MAX's favor: it won't break on such a change :).

>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who are best at talking, realize last or never when they are wrong.
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>