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 <salsa...@gmail.com> 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
>
>
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Schrodinger-devel mailing list
Schrodinger-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/schrodinger-devel
