Hi, I was looking forward to using this in a m.a.m.e. project but for some reason it doesn't correctly decode the mpg files I've got. The files are OK, they play with vlc and all other players I've tried including a hardware decoder :( The decoded data is wrong from frame one :( I've absolutely no idea how to fault finding on this :( I've many files all with similar problems. This is the first frame from a file here. https://drive.google.com/file/d/1_wrjTUzgTOf9hCEqX-G6tlmaoBSp1I2_/view?usp=sharing

Anyone any suggestions or ideas ? Any help is really appreciated. Thanks Paul

I'm using this library with raylib to play MPEG files, it works flawlessly! In under 150 lines of C I got a nice video player!

Just wondering if there is any plan to add a frame/sample seek API. It would be really great.

(I can keep decoding frames/samples to implement a seek mechanism but it seems a bit inefficient)

EDIT: Just created a function to get video length but it's extremely inefficient, it takes up to 10 seconds on my system. I can probably execute it in a second thread while starting playing the video in main thread... but... any better idea to get video length?

int plm_get_total_frames(const char *filename)
{
    int total_frames = 0;
    
    plm_t *plm = plm_create_with_filename(filename);

    if (plm != NULL)
    {
        plm_frame_t *frame = plm_decode_video(plm);
        while (frame != NULL)
        {
            total_frames++;
            frame = plm_decode_video(plm);
        }

        plm_destroy(plm);
    }

    return total_frames;
}

These warnings were annoying me a little bit when compiling with C99 support.

Since the fix was simple, I decided to share it.

In my tests it works on every single compiler (MSVC, mingw, gcc, clang, emscripten, Android, Switch and Vita).

When looping to decode macroblocks you call plm_buffer_no_start_code, which is an aligned check for no start code. I think this can lose undecoded bits in the stream. In the spec it seems they do an unaligned bitcheck for 23 0's. I believe if there were no more macroblocks and the stream wasn't aligned it would be padded with 0's. What do you think?

I'm porting pl_mpeg_player.c to GLFW and it decodes smoothly and accurately, except for these rectangles which appear in the areas of the video which are updating. (The colors are accurate where there is no movement.)

I'm hoping that someone knows at a glance what I'm doing wrong. Is there a step that, when skipped, results in these artifacts? The same artifacting appears regardless of whether I'm using the three-texture YCRCB approach or the one-texture RGB approach; they work equally well and give the same result.

I'd like to thank the creator for his hard work; this is a fantastic library with a ton of utility for creators such as myself.

make large (3X 4X) video files which retain quality. I think this is what most people would want. When I tried this command without this option (-q:v 0) the results were very low quality.

video_buffer keep calling realloc() and keep expanding its memory usage:

In plm_buffer_has_start_code(), the discard_read_bytes is temporarily set to FALSE.

But when it goes all the way to plm_buffer_has(), it will trigger the the load_callback(), which is set to plm_read_video_packet() in plm_init_decoders().

Then plm_buffer_write() will eventually be called when discard_read_bytes is set to FALSE. Finally it causes the video_buffer to keep expanding.

What is happening is that sometimes a slice boundary is blown through because the ISO spec allows for a bit of extra '0' padding at the end, but the current version of PL_MPEG is not quite handling this right. I made a patch which guards the slice boundary based on the known last macroblock address for that specific slice. Tested with several DOSBox ReelMagic MPEG assets and the MPG file posted in this ticket: https://github.com/phoboslab/pl_mpeg/issues/24

When playing video sometimes I get corrupt blocks on the right hand side. When played in VLC media player it is not corrupted.

See example here:

Source file here: https://www.mdawson.net/files/termcrop.mpg

Frame number 980 I wonder if it's something to do with certain motion blocks on the right hand side?

There seem to be some duplicate lines in plm_buffer_has method:

int plm_buffer_has(plm_buffer_t *self, size_t count) {
	if (((self->length << 3) - self->bit_index) >= count) {
		return TRUE;
	}

	if (self->load_callback) {
		self->load_callback(self, self->load_callback_user_data);
	}

	if (((self->length << 3) - self->bit_index) >= count) {
		return TRUE;
	}
	
	if (self->total_size != 0 && self->length == self->total_size) {
		self->has_ended = TRUE;
	}
	return FALSE;
}

For fun I ran american fuzzy lop against this. Here's an MPEG that segfaults when pl_mpeg_extract_frames is run on it. Looks like a wild pointer dereference.

bad.mpg.gz

The compiled exe works but it is not statically linked. I used the following command to compile it:

gcc pl_mpeg_player.c -o pl_mpeg_player.exe -mconsole -lglew32 -lopengl32 -lsdl2

Hello, great library. I am attempting to play a video on the GBA the library compiles fine with devkitpro. However everything decoded is corrupted. For example, my first frame should be completely black. But when grabbing a frame with the library on the gameboy advance it has randomish characters like 7e 6e 0f 0f 00 44 44 FF FF FF instead of being 0's. I can send the project to an email or upload here if interested. It would be awesome if you were. I did verify the same code on windows works. So I know it's GBA specific just not sure what.

Thanks!

Lines 1187 and 1872 involve an assignment within a conditional. Some compilers complain about this. Easy fix: explicitly adding "!= 0" in each conditional appears to work equivalently and silences the warnings.

Hi, I'm looking around for a video playback solution and considering pl_mpeg. Can it be made to work with physfs?? I'm currently using physfs to load resources from a zip archive, so I need to be able to also play the videos from this archive as well. At present I don't see a way to easily do it. Maybe I've overlooked something, please advise.

Thanks

Jarrod

Sometimes we don't have access to the standard library, and/or we want to use custom allocation functions. Thus, it would make sense to add in some defines that can be set by the user of the library before the header is included. These would define memory allocation functions. There will also be a define that controls whether stdio is used, and also remove the *_create_with_file functions to prevent compilation errors. stb_image is an example implementation of this. Of course, it would be trivial for the user to manually modify the source code, and the license is permissive enough. However, it is better to have this be done in a well-defined manner, signed off by someone who has a more intimate knowledge of the code, and therefore is less likely to make mistakes than some impatient newbie running %s/malloc/my_malloc.