I am trying to decode a video of an animated star cascade (for the time being foregoing alpha,
as mentioned in my previous email to the developer mail list entitled “Schroedinger Decoding”).
At an arbitrary time the output shown in VLC version 1.1.11 is this image:
As the video progresses the stars fall down the screen.
Currently my Schroedinger decoder produces the following image:
As my decoder outputs the frames to the display texture the horizontal lines move down the screen.
I am hoping someone has come across output like this in their experiments and can provide me some insight as to why my display texture should contain what amounts to garbage.
- We know the file is good because it works in vlc. – Perhaps VLC uses DiracResearch or an older version of Schroedinger?
- I believe the decoding process is working correctly at least to some degree because I can decode the entire file and schroedingers state transitions appear sensible.
- I believe the issue may lie in either my method of conversion from YUV420p to RGBA32,
or at some random point the texture I am altering with the schroedinger decoded frame data is receiving garbled data, perhaps a buffer overrun or some scoping issue or stray delete’s.
The code I am using for YUV420p to RGBA32 conversion:
// HDTV: Constants for YCbCr conversion to RGBA
//const double wr = 0.2126;
//const double wb = 0.0722;
//const double wg = 1 - wr - wb;
//// SDTV: Constants for YCbCr conversion to RGBA
const double wr = 0.299;
const double wb = 0.114;
const double wg = 0.587;
double EY = CLAMP( (double)*Y, luma_offset, luma_offset + luma_excursion );
double ECb = CLAMP( (double)*U, chroma_offset - chroma_excursion / 2.0, chroma_offset + chroma_excursion / 2.0);
double ECr = CLAMP( (double)*V, chroma_offset - chroma_excursion / 2.0, chroma_offset + chroma_excursion / 2.0);
uint8_t r = CLAMP(EY + 2*(1-wr)*ECr, 0, 255);
uint8_t g = CLAMP(EY - ((2*wr*(1-wr) * ECr)/wg) - ((2*wb*(1-wb)*ECb)/wg), 0 ,255);
uint8_t b = CLAMP(EY + 2*(1-wr)*ECb, 0, 255);
On another point David Schleef tried pointing me to some dirac test streams, which don’t seem to work with my decoder. When decoding is attempted they return the error state SCHRO_DECODER_ERROR.
The test streams seem to have been encoded with Schroedinger 1.0.9 whilst I am using version 1.0.10. Is the error state expected in this case?
Although it looks like garbage I believe it is decoding the video correctly to a degree as the output image seems to alter in the same way as the vlc output.
The purplish lines scatter down screen at the same speed as the stars cascade in the vlc output and it plays for the same length of time.
Any help or guidance as always greatly appreciated.
I have been trying to write a decoder using libschroedinger for the last couple of days. I used ffmpeg to generate a schroedinger encoded ogg video file with no audio using an uncompressed avi video as input. My decoder parses the ogg file pulling out an ogg_packet then decodes it, which all appears to work fine.
My first question is ffmpeg encoding using libschroedinger seems to force the output to use the YUV420 colour space even when specifically requesting other pixel formats using the ffmpeg –pix_fmt option. Looking at the schro_frame.h file there appears to be indirect support for SCHRO_FRAME_FORMAT_ARGB which would be the ideal format for my purposes; would you be able to explain what indirect support actually implies here? It also appears schroedinger only caters for three components (read: colour channels) so how is Alpha supported in schroedinger / dirac? i.e. will I need to add the alpha support into schroedinger myself or like other non-alpha codecs would I have to encode the alpha in the luma component of a grayscale frame?
Finally when storing my frame data in the SCHRO_DECODER_OK state I find the Schro_Frame occasionally contains NULL data. Meaning my conversion from YUV420 colour space to RGB cannot proceed for this frame. Is a null frame expected in this way?
If anyone can provide a link to a dummy video file with expected schroedinger state transitions that would be fantastic as I could prove my decoder code against known working decoders.
Thanks for any and all help you can provide.