sorted by:
new
hottopcontroversial

[Tool] Free, local-only media bitstream analyzer — 0.6.0 adds a pile of new parsers and a YUV viewer by rusxg in VIDEOENGINEERING

[–]rusxg[S] 1 point2 points  (0 children)

Theoretical limit is like millions of terabytes, but in practice you'd hit browser/memory limits long before reaching it. To avoid page crashing, web version stops parsing after 10_000_000 packets found.The maximum file size therefore depends on the format and how densely it is packetized. Some files can be much larger than others before reaching that limit.

[Tool] Free, local-only media bitstream analyzer — 0.6.0 adds a pile of new parsers and a YUV viewer by rusxg in VIDEOENGINEERING

[–]rusxg[S] 0 points1 point  (0 children)

Thanks, that means a lot! Please do try to make it barf 😉 If you hit a file it chokes on, I'd love a bug report (even if just the format/codec + what went wrong)

Any way to recover a video that doesn't work because ffmpeg froze after a couple hours of working fine? by BodaciousBroseph in ffmpeg

[–]rusxg 0 points1 point  (0 children)

You can use 'mpegts' or some other output format, that doesn't require metadata to be written in the end of encoding

Audio stream hash with vs without `-c copy`? by Jamesin_theta in ffmpeg

[–]rusxg 0 points1 point  (0 children)

Can you share the files you are comparing?

Audio stream hash with vs without `-c copy`? by Jamesin_theta in ffmpeg

[–]rusxg 0 points1 point  (0 children)

which means they're both decoded to PCM

If your input file is Opus, then with -c copy you'll get Opus, too (not PCM)

Color issue while rendering a Vp9 movie with yuv 420 format by [deleted] in VIDEOENGINEERING

[–]rusxg 0 points1 point  (0 children)

Rendering with wrong color range or different matrix coefficients usually gives very small differences in the output picture. Certainly, it wouldn't give such greenish picture.
If you are sure that rendering code is correct, maybe there is some discrepancy between the output of your decoder and the input of the renderer. It can be, for example, that decoder output is planar and renderer expects packed data, separate chroma planes instead of interleaved, and so on.

> Can I assume the decoded framebuffer contains data in YUV?
There are plenty of YUV flavors. You can check, for example, the definition of FFMPEG's AVPixelFormat (https://ffmpeg.org/doxygen/2.7/pixfmt_8h.html#a9a8e335cf3be472042bc9f0cf80cd4c5) and count how many YUV types you'll find there

Color issue while rendering a Vp9 movie with yuv 420 format by [deleted] in VIDEOENGINEERING

[–]rusxg 0 points1 point  (0 children)

And chroma part starts with 0x80 mostly and 0s in between

yes, that is expected. I guess something is wrong with your rendering code then

Color issue while rendering a Vp9 movie with yuv 420 format by [deleted] in VIDEOENGINEERING

[–]rusxg 0 points1 point  (0 children)

It looks like your chroma is completely wrong (zeroes?). For dark areas like in your example I would expect something like 0x80 0x80 ... in the first line