On Thu, Nov 13, 2008 at 2:54 PM, David Flynn <[EMAIL PROTECTED]> wrote:
> The only niggle i have with this file is that the EOS page has a bizare > timestamp. imho, because there is no picture in the eos page, there is > no meaningful time for it, so the granulepos should be -1 on the eos > page on the dirac logical stream. ds and I talked about this a bit yesterday. The rfc says the special value of 0xFFFFFFFFFFFFFFFF "indicates that no packets finish on that page." So it's a bit misleading to say this. Moreover, it's convenient for duration calculation (and scanning backward) if the final page has a granulepos. With other mappings, when considering a non-frame eos page, we've generally concluded it's better that it carry the same granulepos as the last frame. In this case, the page has a packet, and while that packet affects decoder state, it doesn't itself advance production of decodeable output, so it make some sense for it to have presentation timestamp the same as the last decodable frame in the stream, and perhaps a decode timestamp likewise the same. Does this not make sense in the dirac granulepos encoding? -r ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Schrodinger-devel mailing list Schrodinger-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/schrodinger-devel
