6 ms·

MPEG1 Single file C library

96 points by phoboslab 7y ago

jhallenworld 7y ago
Do you have the encoder side of this also?
xmichael999 7y ago
Excellent stuff, really excellent. Thanks for the additional links and cool tangents too!
commandlinefan 7y ago
Love to see stuff like this. I wonder why he put all of the code in a header file, though... I've never seen that done before; it seems like it would make it impossible to invoke this from two separate source files?
- mmozeiko 7y ago
  Here's a rationale for this from an author of very popular many single-header libraries: https://github.com/nothings/stb#why-single-file-headers https://github.com/nothings/stb#why-single-file-headers As to how to use from two separate translation units - you need to define PL_MPEG_IMPLEMENTATION to actually include implementation. So you do that in one of your .c files. Rest of includes will have only declarations included.
- zzo38computer 7y ago
  I like it too, to have just one file rather than many large and complicated files. Some programs I have seen do put everything in the header file, although I prefer to have a separate header file and program file, although having only the header file still works too. It isn't impossible to invoke from two separate source files, because there is a macro that you can define to specify if you want to include the implementation or not.
- newnewpdro 7y ago
  It's somewhat trendy these days, but the main reason I've found is windows developers struggle with adding third-party dependencies to their projects because their development environment sucks.
  - kevin_thibedeau 7y ago
    I think it's mostly game devs backporting C++ flaws into C.
  - Impossible 7y ago
    Although this is getting downvoted because it is somewhat inflammatory (stops just short of using "winblowz" and "M$"), there is some truth to it. Visual Studio does have a package manager but its not widely used, and in practice can't be used in a lot of environments that C\C++ Windows developers (often game developers) are using. That said, I've seen stb_image used widely in environments that are not Windows because even if you have package manager and a build system that manages dependencies better than vanilla MSBuild it's still lower friction to include a single header file library. Last time I used xcode, dependency management was about as painful as visual studio but I might have been doing it wrong.
- blondin 7y ago
  single headers (take it from a non c/c++ expert here just observing): 1. speeds up compilation -- through a single compilation unit. which as far as i understand is making the compiler compile a single "huge" pile of code. and because computers are extremely fast, is faster than figuring out dependencies using a build tool 2. makes dependency management easier (no make, no cmake, no scons, no ninja, etc.) 3. makes customization easier (just drop a macro and you can include just want you need) i love the idea and empathize with the need for it.
VikingCoder 7y ago
How long until someone emscripten's this, so it runs directly in JS in the browser? And how would that compare to others? https://jsmpeg.com/ https://jsmpeg.com/
- ScottFree 7y ago
  I'm guessing there won't be much difference since jsmpeg already has a small chunk of C code that gets run through emscripten and both libraries are written by the same guy. https://github.com/phoboslab/jsmpeg/blob/master/build.sh https://github.com/phoboslab/jsmpeg/blob/master/build.sh
- andyjpb 7y ago
  jsmpeg is by the same author!
- flohofwoe 7y ago
  Here you go :) https://floooh.github.io/sokol-html5/plmpeg-sapp.html https://floooh.github.io/sokol-html5/plmpeg-sapp.html
Scaevolus 7y ago
MPEG2 is mostly patent-free too now, though I'm not sure how much larger its decoder would be.
- keithwinstein 7y ago
  The core of libmpeg2 is 3,810 lines of C (not including any systems-stream demultiplexer or audio decoder) versus about 2,400 for pl_mpeg.h. So not dramatically larger. On the other hand, for progressive-scan 30fps video on computers without a VBV constraint and with a deterministic known decoder, I'm not sure any of the extra features in the MPEG-2 spec are very helpful compared with MPEG-1.
- ksec 7y ago
  According to MPEG-LA [1] Please note that the last US patent expired February 13, 2018, and patents remain active in Philippines and Malaysia after that date. [1] https://www.mpegla.com/programs/mpeg-2/patent-list/ https://www.mpegla.com/programs/mpeg-2/patent-list/
izacus 7y ago
> This gross oversight in the overengineered (especially for its time) MPEG-PS and MPEG-TS container formats just leaves me dumbfounded. If anybody knows why the MPEG standard doesn't just provide a byte size in the header of each frame or even just a FRAME_END code, or if you have a solution for this problem, let me know! Because the video encoding was created in 1988 and the mux format in 1995 when large amounts of fast RAM were incredibly expensive and recording/transcoding and processing devices didn't always even have a framebuffer to store a full frame. Many many MPEG-1, MPEG-2 and even MPEG4 AVC Baseline limitations become very obvious when you consider that they were encoded on CPUs that might be slower than 150MHz and be decoded on devices which may only have a few macroblocks worth of storage for decoded frame. > Interestingly, if I interpret the source correctly, ffmpeg chose the second option (waiting for the next PICTURE_START_CODE) even for the MPEG-TS container format, which is meant for streaming. So demuxing MPEG-TS with ffmpeg always introduces a frame of latency. I think the confusion here is because MPEG-TS was created for broadcast TV streaming, not realtime streaming. Broadcast TV can easily be seconds behind the source these days and has probably travelled at least once from geostationary orbit so one frame really isn't something anyone cares about. The more modern HLS/DASH formats tend to be even worse at this, with many sources waiting for a full several-second long chunk to be complete before transmitting it to the viewer's device.
- andyjpb 7y ago
  Even if you had enough RAM, storing the frame at the encoder just to calculate its length would force a frame of latency at the encoder. The way it is, the decoder has more flexibility in implementation.
- andyjpb 7y ago
  Buffering a several second chunk allows the transmitter to include forward error correction (FEC). This allows operators to trade off latency for stream integrity which is important when it's going to be transmitted over a lossy medium such as terrestrial broadcast. This differs from the size problem because the amount of FEC (if any) is a parameter that can be configured between encoder and decoder. A size header would be a built in part of the protocol: hence my assertion that it would force a frame of latency. i.e. FEC is an operational concern whereas the size header is a protocol design concern.
ksec 7y ago
I have been wondering if we could built something on top of MPEG2 and AC3 and MP3, Codec with patents that had expired and something that is truly patents free. Which reminds me of Musepack, based on MPEG-1 Layer 2 [1]. Truly amazing quality at the time even when comparing to high bitrate AAC. [1] https://www.musepack.net https://www.musepack.net
deleted 7y ago
[deleted]
taneq 7y ago
As an aside, it makes me happy that Bink is still around. I remember using their Bink video codec for VJing way back in 2000 or whatever.

96 points by phoboslab 7y ago

jhallenworld 7y ago

Do you have the encoder side of this also?

xmichael999 7y ago

Excellent stuff, really excellent. Thanks for the additional links and cool tangents too!

commandlinefan 7y ago

Love to see stuff like this. I wonder why he put all of the code in a header file, though... I've never seen that done before; it seems like it would make it impossible to invoke this from two separate source files?

mmozeiko 7y ago
Here's a rationale for this from an author of very popular many single-header libraries: https://github.com/nothings/stb#why-single-file-headers https://github.com/nothings/stb#why-single-file-headers As to how to use from two separate translation units - you need to define PL_MPEG_IMPLEMENTATION to actually include implementation. So you do that in one of your .c files. Rest of includes will have only declarations included.
zzo38computer 7y ago
I like it too, to have just one file rather than many large and complicated files. Some programs I have seen do put everything in the header file, although I prefer to have a separate header file and program file, although having only the header file still works too. It isn't impossible to invoke from two separate source files, because there is a macro that you can define to specify if you want to include the implementation or not.
newnewpdro 7y ago
It's somewhat trendy these days, but the main reason I've found is windows developers struggle with adding third-party dependencies to their projects because their development environment sucks.
- kevin_thibedeau 7y ago
  I think it's mostly game devs backporting C++ flaws into C.
- Impossible 7y ago
  Although this is getting downvoted because it is somewhat inflammatory (stops just short of using "winblowz" and "M$"), there is some truth to it. Visual Studio does have a package manager but its not widely used, and in practice can't be used in a lot of environments that C\C++ Windows developers (often game developers) are using. That said, I've seen stb_image used widely in environments that are not Windows because even if you have package manager and a build system that manages dependencies better than vanilla MSBuild it's still lower friction to include a single header file library. Last time I used xcode, dependency management was about as painful as visual studio but I might have been doing it wrong.
blondin 7y ago
single headers (take it from a non c/c++ expert here just observing): 1. speeds up compilation -- through a single compilation unit. which as far as i understand is making the compiler compile a single "huge" pile of code. and because computers are extremely fast, is faster than figuring out dependencies using a build tool 2. makes dependency management easier (no make, no cmake, no scons, no ninja, etc.) 3. makes customization easier (just drop a macro and you can include just want you need) i love the idea and empathize with the need for it.

VikingCoder 7y ago

How long until someone emscripten's this, so it runs directly in JS in the browser? And how would that compare to others? https://jsmpeg.com/ https://jsmpeg.com/

ScottFree 7y ago
I'm guessing there won't be much difference since jsmpeg already has a small chunk of C code that gets run through emscripten and both libraries are written by the same guy. https://github.com/phoboslab/jsmpeg/blob/master/build.sh https://github.com/phoboslab/jsmpeg/blob/master/build.sh
andyjpb 7y ago
jsmpeg is by the same author!
flohofwoe 7y ago
Here you go :) https://floooh.github.io/sokol-html5/plmpeg-sapp.html https://floooh.github.io/sokol-html5/plmpeg-sapp.html

Scaevolus 7y ago

MPEG2 is mostly patent-free too now, though I'm not sure how much larger its decoder would be.

keithwinstein 7y ago
The core of libmpeg2 is 3,810 lines of C (not including any systems-stream demultiplexer or audio decoder) versus about 2,400 for pl_mpeg.h. So not dramatically larger. On the other hand, for progressive-scan 30fps video on computers without a VBV constraint and with a deterministic known decoder, I'm not sure any of the extra features in the MPEG-2 spec are very helpful compared with MPEG-1.
ksec 7y ago
According to MPEG-LA [1] Please note that the last US patent expired February 13, 2018, and patents remain active in Philippines and Malaysia after that date. [1] https://www.mpegla.com/programs/mpeg-2/patent-list/ https://www.mpegla.com/programs/mpeg-2/patent-list/

izacus 7y ago

> This gross oversight in the overengineered (especially for its time) MPEG-PS and MPEG-TS container formats just leaves me dumbfounded. If anybody knows why the MPEG standard doesn't just provide a byte size in the header of each frame or even just a FRAME_END code, or if you have a solution for this problem, let me know! Because the video encoding was created in 1988 and the mux format in 1995 when large amounts of fast RAM were incredibly expensive and recording/transcoding and processing devices didn't always even have a framebuffer to store a full frame. Many many MPEG-1, MPEG-2 and even MPEG4 AVC Baseline limitations become very obvious when you consider that they were encoded on CPUs that might be slower than 150MHz and be decoded on devices which may only have a few macroblocks worth of storage for decoded frame. > Interestingly, if I interpret the source correctly, ffmpeg chose the second option (waiting for the next PICTURE_START_CODE) even for the MPEG-TS container format, which is meant for streaming. So demuxing MPEG-TS with ffmpeg always introduces a frame of latency. I think the confusion here is because MPEG-TS was created for broadcast TV streaming, not realtime streaming. Broadcast TV can easily be seconds behind the source these days and has probably travelled at least once from geostationary orbit so one frame really isn't something anyone cares about. The more modern HLS/DASH formats tend to be even worse at this, with many sources waiting for a full several-second long chunk to be complete before transmitting it to the viewer's device.

andyjpb 7y ago
Even if you had enough RAM, storing the frame at the encoder just to calculate its length would force a frame of latency at the encoder. The way it is, the decoder has more flexibility in implementation.
andyjpb 7y ago
Buffering a several second chunk allows the transmitter to include forward error correction (FEC). This allows operators to trade off latency for stream integrity which is important when it's going to be transmitted over a lossy medium such as terrestrial broadcast. This differs from the size problem because the amount of FEC (if any) is a parameter that can be configured between encoder and decoder. A size header would be a built in part of the protocol: hence my assertion that it would force a frame of latency. i.e. FEC is an operational concern whereas the size header is a protocol design concern.

ksec 7y ago

I have been wondering if we could built something on top of MPEG2 and AC3 and MP3, Codec with patents that had expired and something that is truly patents free. Which reminds me of Musepack, based on MPEG-1 Layer 2 [1]. Truly amazing quality at the time even when comparing to high bitrate AAC. [1] https://www.musepack.net https://www.musepack.net

deleted 7y ago

[deleted]

taneq 7y ago

As an aside, it makes me happy that Bink is still around. I remember using their Bink video codec for VJing way back in 2000 or whatever.