Another thing I have just noticed, it seems that the decoder starts up a
background thread which continues processing even outside
schro_decoder_wait().
This is causing memory conflicts with the host application and it is
crashing when the decoder thread and the main thread both try to allocate
memory.
Is there any way to disable this background processing of frames ?
Regards,
Salsaman.
http://lives.sourceforge.net
https://www.ohloh.net/accounts/salsaman
On Sat, Jun 12, 2010 at 5:56 PM, salsaman <salsa...@gmail.com> wrote:
> 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
