Re: [Schrodinger-devel] GSOC project and some questions

[salsaman <sal...@gm...>]

Hi,
I am a bit disappointed that nobody has responded directly to my queries
yet.

Anyway I am continuing on with my work on the vlc and LiVES dirac decoders.

I have a few more questions which may be easier to answer.

First of all in vlc, they are using the functions:

    schro_decoder_autoparse_push();

        state = schro_decoder_autoparse_wait();


However, in the documentation I have it only mentions

schro_decoder_push and schro_decoder_wait().


I would like to know what is the difference with the autoparse versions ? Is
one set now deprecated in favour of the other ?




Secondly, I noticed that the first frame number from
schro_decoder_get_picture_number() is 32. Is that normal ? Why is it 32 and
not 0 or 1 ?



I would also appreciate it if somebody could confirm that the flow I am
using is OK.

- pull packets from ogg stream

- create a SchroBuffer from the ogg packet

- pass buffer to decoder via  schro_decoder_autoparse_push

loop:
- check state with schro_decoder_autoparse_wait

-- if state is BITS_NEEDED exit loop and get another packet from stream

- if state is FRAME_NEEDED, create a SchroFrame with schro_frame_new, and
set the width, height and allocate component.data planes, etc then call
schro_decoder_add_output_picture; goto loop

- if state is SCHRO_DECODER_OK, get back the SchroFrame via
schro_decoder_pull();
    goto loop



What I am seeing is the first frame comes out OK, but then if I rewind the
stream to the data start and begin decoding again, the frames look messed
up, and I see errors like:

SCHRO: ERROR: schromotion.c(921): schro_motion_verify: mv(4,0) has bad DC
value [1] 322

(and yes, I am calling schro_decoder_reset() when I rewind)


Code can be seen here:
http://lives.svn.sourceforge.net/viewvc/lives/trunk/lives-plugins/plugins/decoders/ogg_decoder.c

any help would be appreciated.


Cheers,
Salsaman.




http://lives.sourceforge.net
https://www.ohloh.net/accounts/salsaman



On Mon, May 17, 2010 at 5:01 PM, salsaman <sal...@gm...> wrote:

> Hi all,
> some of you may know me already, I am the main developer of LiVES (
> http://lives.sourceforge.net), contributor to frei0r (
> http://en.wikipedia.org/wiki/Frei0r), and videojack (
> http://videojack.sourceforge.net), amongst other things.
>
> This year I will be working on a GSOC project for vlc. The aim of the
> project is to rewrite the vlc ogg demuxer. I am quite familiar with
> ogg/theora, but part of this work will also involve looking at the ogg/dirac
> format. I am hoping also that what I learn from this experience will help
> with porting dirac more fully into LiVES as well.
>
>
>
>
>
> I had a brief look at the dirac in ogg pdf, and a few things are still not
> clear to me.
>
> http://diracvideo.org/download/mapping-specs/dirac-mapping-ogg-latest.pdf
>
> Section 6.1:
>
> "        It is advisable that, the first packet after the logical stream
> BOS page contains an additional Dirac Se-
> quence Header data unit to facilitate random access.
> "
>
> What is a Dirac Sequence Header, and how does it facilitate random access ?
>
>
>
>
> Section 6.2:
>
> "It is advisable to flush the Ogg page after each encapsulation unit"
>
> Does this mean that if an encapsulation unit (==packet ?) finishes on a
> page, the rest of the page data is irrelevant ?
>
>
>
> Section 6.3:
>
> "             The granule position applies to the picture contained within
> the first packet that terminates in
> an Ogg page;"
>
> This seems to contradict section 6.2, above, and:
>
> "In a logical stream of Dirac, an Ogg page should not terminate multiple
> Ogg packets."
>
>
>
>  "           The granule position applies to the picture contained within
> the first packet that terminates in
> an Ogg page"
>
> so that would be the opposite of theora, where the granulepos denotes the
> *last* frame decoded in the packet ? Again, this seems to contradict the
> earlier sentence "an Ogg page should not terminate multiple ogg packets".
>
>
>
>
> Now, looking at annex A, it would appear that the "sync point" varies from
> picture to picture. So the question here is, if a picture doesn't have a
> granulepos, how can one tell where the sync point for it is ?
>
>
>
> Finally, it says:
>
> "How to find the appropriate sync point for a particular picture: the dt of
> the sync point is: dt - dist; this may be
> converted to the higher order bits of granule position: (dt - dist) ¡¡ 31;
> the lower order bits are undefined."
>
> What does "the lower order bits are undefined mean", and what is this
> symbol ¡¡ ?
>
>
>
> Thanks in advance,
> Salsaman.
>
>
>
>
>
> http://lives.sourceforge.net
> https://www.ohloh.net/accounts/salsaman
>
>