Felix Domke wrote:
Johannes Stezenbach wrote:
The V4 API has:
unsigned int frame_rate; /* in frames per 1000sec */
I'm against this.
The reason is that arbitrary framerates are not allowed in MPEG-2
(correct me if i'm wrong, i'm currently too lazy to read 13818-2
again...), and there's no hardware being able to playback this simply
because there's no TV standard for arbitrary framrates.
I use the framerate to decide wheter to have a PAL or NTSC stream, or
better: if the stream is more likely to comply with the NTSC standard or
the PAL standard (or in future any HDTV standard). I think handling the
"odd" framerates (23.976 etc.) is hard enough - what is the application
expect to do if the framerate becomes, for example, 31337? (switching to
eTSC?) Dropping frames and do simple NTSC?
Seriously, are there are really real-world-cases where the enum proposed
by Andreas isn't enough? I really would like to restrict us here to the
real-world framerates, since only this will give you the possibility to
handle all values correctly.
After all, we don't want to insert any "frame rate drift" etc. here,
since that's not what the value should say. It should only give a hint
wheter to display the source in NTSC or PAL and maybe some informational
output.
(Of course if someone tells me that arbitrary framerates are of any(!)
use, i'll change my position here, but after all, it's a DVB-API, not a
generic stream playback API. MPEG was restricted to a set of discret
frame rates, because it's simply impossible to build a decoder which
supports all frame rates without doing complex pullup/downs).
DVB has TV oriented requirements (i.e. frame rate matching PAL
or NTSC), but MPEG-2 can also be used for special purpose stuff
like CCTV or info terminals (used in public places like museums),
where low frame rates are sufficient.
Also, newer STB/DVD chips might support MPEG-4 or other codecs,
and you cannot predict what frame rates you have to deal with.
But of course no one expects a STB to play back everything flawlessly,
it's just that IMHO the DVB API should allow for some non-DVB
extensions.
the nom/denom notation is in opposite to the frames/msec notation always
correct and can display all usual framerates without rounding - so I'd
vote for this one.