TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

MPEG1 Single file C library

96 pointsby phoboslabalmost 6 years ago

8 comments

izacusalmost 6 years ago
&gt; 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&#x27;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!<p>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&#x2F;transcoding and processing devices didn&#x27;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.<p>&gt; 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.<p>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&#x27;t something anyone cares about. The more modern HLS&#x2F;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&#x27;s device.
评论 #20649588 未加载
评论 #20648981 未加载
评论 #20648940 未加载
Scaevolusalmost 6 years ago
MPEG2 is mostly patent-free too now, though I&#x27;m not sure how much larger its decoder would be.
评论 #20649473 未加载
评论 #20649789 未加载
jhallenworldalmost 6 years ago
Do you have the encoder side of this also?
ksecalmost 6 years 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.<p>[1] <a href="https:&#x2F;&#x2F;www.musepack.net" rel="nofollow">https:&#x2F;&#x2F;www.musepack.net</a>
commandlinefanalmost 6 years ago
Love to see stuff like this. I wonder why he put all of the code in a header file, though... I&#x27;ve never seen that done before; it seems like it would make it impossible to invoke this from two separate source files?
评论 #20648191 未加载
评论 #20649166 未加载
评论 #20649576 未加载
评论 #20648706 未加载
VikingCoderalmost 6 years ago
How long until someone emscripten&#x27;s this, so it runs directly in JS in the browser?<p>And how would that compare to others?<p><a href="https:&#x2F;&#x2F;jsmpeg.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jsmpeg.com&#x2F;</a>
评论 #20649808 未加载
评论 #20648778 未加载
评论 #20648782 未加载
taneqalmost 6 years 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.
xmichael999almost 6 years ago
Excellent stuff, really excellent. Thanks for the additional links and cool tangents too!