OK, ignore that last part, it was due to an error in my own code.
But I would still like to know:
a) what is the picture number of the first frame ? If I start decoding from
the very start of the file, it comes out as 0. But if I start decoding from
just after the ogg BOS packets, it comes out as 32. Which is correct ?
b) what are the *autoparse* functions ? The only difference I have notices
so far is that they seem to handle EOS themselves. Is that correct ?
Regards,
Salsaman.
http://lives.sourceforge.net
https://www.ohloh.net/accounts/salsaman
On Sat, Jun 12, 2010 at 6:19 PM, salsaman <salsa...@gmail.com> wrote:
> 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
