Lossless video codec for web use?

[Eric Shepherd (Sheppy)]

I’m working on my video codec documentation and have come across the point
where I need to offer suggestions to developers who need to work with
lossless video in a web app, for things like archival and video production
work?

As far as I can see, there aren’t at this time any dedicated lossless video
codecs available in web browsers. Is there a lossless profile of one of the
existing major codecs (AAC, AV1, VP8, or VP9 being the prime candidates, I
suspect)?

Some of them include a lossless functionality in the spec but the question
is whether or not that capability is implemented by browsers and exposed in
turn to the web app developer.

Any input appreciated, thanks!


Eric Shepherd
Senior Technical Writer
MDN Web Docs <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/

[Martin Thomson]

Lossless video coding isn't really a thing on the internet. There are
lossless modes in some encoders (x264 has one that I'm aware of), but they
tend to inflate inputs rather than compress them. There are systems used
in video production that maintain all the source bits, but they use insane
amounts of bandwidth.

> _______________________________________________
> dev-media mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media
>

[Eric Shepherd (Sheppy)]

Yeah, I know that lossless is huge, but was curious if there were any
options since it will be a question that gets asked, and therefore I want
to be prepared. My experiements suggest that even where there are codecs
that have a lossless or near-lossless feature in the spec, they tend not to
be implemented, especially in browsers. So I guess that’ll be a big “nope”
for now… unless someone has further guidance.

On June 13, 2019 at 6:23:00 PM, Martin Thomson (m...@mozilla.com) wrote:

Lossless video coding isn't really a thing on the internet. There are
lossless modes in some encoders (x264 has one that I'm aware of), but they
tend to inflate inputs rather than compress them. There are systems used
in video production that maintain all the source bits, but they use insane
amounts of bandwidth.

[Eric Shepherd (Sheppy)]

Hit send one sentence too soon. I also meant to point out that in web apps,
the user could be working with local media files rather than something over
the web — especially if they’re doing A/V production work.

On June 13, 2019 at 6:23:00 PM, Martin Thomson (m...@mozilla.com) wrote:

Lossless video coding isn't really a thing on the internet. There are
lossless modes in some encoders (x264 has one that I'm aware of), but they
tend to inflate inputs rather than compress them. There are systems used
in video production that maintain all the source bits, but they use insane
amounts of bandwidth.

On Fri, Jun 14, 2019 at 6:37 AM Eric Shepherd (Sheppy) <
eshe...@mozilla.com> wrote:

> I’m working on my video codec documentation and have come across the point
> where I need to offer suggestions to developers who need to work with
> lossless video in a web app, for things like archival and video production
> work?
>
> As far as I can see, there aren’t at this time any dedicated lossless video
> codecs available in web browsers. Is there a lossless profile of one of the
> existing major codecs (AAC, AV1, VP8, or VP9 being the prime candidates, I
> suspect)?
>
> Some of them include a lossless functionality in the spec but the question
> is whether or not that capability is implemented by browsers and exposed in
> turn to the web app developer.
>
> Any input appreciated, thanks!
>
>

> Eric Shepherd
> Senior Technical Writer
> MDN Web Docs <https://developer.mozilla.org/>
> Blog: https://www.bitstampede.com/

> _______________________________________________
> dev-media mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media
>

[Jeremy Noring]

Regarding "near lossless," the best option I've seen is using x264 with
"-crf 18 -preset ultrafast", which is basically a very high quality copy of
the video with a high bitrate due to the "ultrafast" preset. There's
minimal loss of fidelity, but it's also still relatively quick to do the
encode because x264 is exceptionally performant.

I use this extensively in a video processing pipeline I wrote (2
million-ish videos a month, at the moment). It's a total lifesaver,
because processing video in a lossless way requires such a huge amount of
storage/memory that it's almost not worth consideration for anything but
digital mastering of original content. A better approach in probably ~95%
of situations is a "near lossless" approach.

On Thu, Jun 13, 2019 at 4:28 PM Eric Shepherd (Sheppy) <
eshe...@mozilla.com> wrote:

> Yeah, I know that lossless is huge, but was curious if there were any
> options since it will be a question that gets asked, and therefore I want
> to be prepared. My experiements suggest that even where there are codecs
> that have a lossless or near-lossless feature in the spec, they tend not to
> be implemented, especially in browsers. So I guess that’ll be a big “nope”
> for now… unless someone has further guidance.
>
>

> On June 13, 2019 at 6:23:00 PM, Martin Thomson (m...@mozilla.com) wrote:
>
> Lossless video coding isn't really a thing on the internet. There are
> lossless modes in some encoders (x264 has one that I'm aware of), but they
> tend to inflate inputs rather than compress them. There are systems used
> in video production that maintain all the source bits, but they use insane
> amounts of bandwidth.
>
>

[Adam Roach]

On 6/13/19 5:28 PM, Eric Shepherd (Sheppy) wrote:
> Yeah, I know that lossless is huge, but was curious if there were any
> options since it will be a question that gets asked, and therefore I want
> to be prepared. My experiements suggest that even where there are codecs
> that have a lossless or near-lossless feature in the spec, they tend not to
> be implemented, especially in browsers. So I guess that’ll be a big “nope”
> for now… unless someone has further guidance.

The only adjustment I'd make is that "for now" implies that real-time
lossless video transmission across the public internet might become
available in the foreseeable future.

Uncompressed 1080p video at 4:2:0 color sampling minimally takes 1.5
Gbps. Lossless compression like FFV1 would knock that down to ~600 Mbps,
depending on the source material (it does somewhere between 2:1 and 3:1
for most video sources). It is going to be quite a long time before this
is realistically something that anyone outside a research environment
can take advantage of.

/a

[Timothy B. Terriberry]

Adam Roach wrote:
> On 6/13/19 5:28 PM, Eric Shepherd (Sheppy) wrote: >> to be prepared. My experiements suggest that even where there are

codecs>> that have a lossless or near-lossless feature in the spec, they
tend >> not to>> be implemented, especially in browsers. So I guess
that’ll be a big >> “nope”>> for now… unless someone has further guidance.

VP9 has a lossless mode that is not completely terrible and, as far as I
know, it is supported by every browser that implements VP9. If you know
of one that does not support it, I'd be very interested to learn that.

That doesn't invalidate anything that Adam said about the practical
limitations of public networks, of course.

[Eric Shepherd (Sheppy)]

That’s really good advice and I’ll tweak my content around that. Thanks to
both of you for your input. I still personally feel like there’s room for
using device-local uncompressed media in a media editing context, but I
suppose that’s a pretty incredibly niche market. :)

On June 13, 2019 at 6:36:38 PM, Jeremy Noring (jeremy...@gmail.com)
wrote:

Regarding "near lossless," the best option I've seen is using x264 with
"-crf 18 -preset ultrafast", which is basically a very high quality copy of
the video with a high bitrate due to the "ultrafast" preset. There's
minimal loss of fidelity, but it's also still relatively quick to do the
encode because x264 is exceptionally performant.

I use this extensively in a video processing pipeline I wrote (2
million-ish videos a month, at the moment). It's a total lifesaver,
because processing video in a lossless way requires such a huge amount of
storage/memory that it's almost not worth consideration for anything but
digital mastering of original content. A better approach in probably ~95%
of situations is a "near lossless" approach.

[Jeremy Noring]

I think you’re correct regarding the “niche” comment. As a video engineer
I have yet to see a situation where I lossless compression made sense, but
video processing is a big field and I’m sure there are places it’s
appropriate.

[Eric Shepherd (Sheppy)]

You suggest H.264 here. Any thoughts on whether or not you can get better
results with HEVC? I would expect people to wonder if the newer codec can
get better results, so I figured I should ask.

On June 13, 2019 at 6:36:38 PM, Jeremy Noring (jeremy...@gmail.com)
wrote:

Regarding "near lossless," the best option I've seen is using x264 with
"-crf 18 -preset ultrafast", which is basically a very high quality copy of
the video with a high bitrate due to the "ultrafast" preset. There's
minimal loss of fidelity, but it's also still relatively quick to do the
encode because x264 is exceptionally performant.

[Eric Shepherd (Sheppy)]

We used to use lossless compression during the compositing and mastering
process while preparing videos for use in video games, back when I worked
in the game business — but the lossy codecs were much worse back then, so
perhaps it’s no longer as useful. I agree that generally speaking, the only
people who would even possibly need to do it are professional film editors
—possibly only the ones at major film studios -- and there just aren’t that
many of those. :)

On June 15, 2019 at 1:23:14 PM, Jeremy Noring (jeremy...@gmail.com)
wrote:

I think you’re correct regarding the “niche” comment. As a video engineer
I have yet to see a situation where I lossless compression made sense, but
video processing is a big field and I’m sure there are places it’s
appropriate.

[Jeremy Noring]

No, because HEVC encoder implementations are extraordinarily slow, so it
defeats the purpose of the trick I just mentioned. The reason x264 is
great is you get a very high quality copy and the performance of the
encoder is exceptionally good on regular old x86 hardware. You could use
HEVC/AV1; you'd probably use half the bits for 10-100x slower encode time.

On Sun, Jun 16, 2019 at 8:25 AM Eric Shepherd (Sheppy) <
eshe...@mozilla.com> wrote:

> You suggest H.264 here. Any thoughts on whether or not you can get better
> results with HEVC? I would expect people to wonder if the newer codec can
> get better results, so I figured I should ask.
>

> On June 13, 2019 at 6:36:38 PM, Jeremy Noring (jeremy...@gmail.com)

> wrote:
>
> Regarding "near lossless," the best option I've seen is using x264 with
> "-crf 18 -preset ultrafast", which is basically a very high quality copy of
> the video with a high bitrate due to the "ultrafast" preset. There's
> minimal loss of fidelity, but it's also still relatively quick to do the
> encode because x264 is exceptionally performant.
>
>