Since the last time I wrote about it somebody actually decided to test my transcoder on a bunch of fringe formats. The main issue there was wrong audio output (since I didn’t bother to check the actual input format, it often passed e.g. floating-point audio as 16-bit PCM, resulting in complete garbage). Additionally I’ve fixed a stupid bug in Indeo IVF demuxer (so now both known samples are decoded fine) as well as improving support for some other corner cases.
And there was one fun failure only my transcoder could have: when video streams starts with skip frame(s) and ZMBV encoder was selected, it refused to encode. I’ve added a work-around so now it simply presumes that frame to be black and goes forth normally (if you encode into raw video, such initial frames would be skipped instead).
So whatever can be decoded seems to be decoded and re-encoded just fine (but there are probably more cases waiting for their turn to be discovered). And there are some more formats waiting for an open-source decoder (in case of Motion Pixels the wait is likely to be very long).
With rustc/catgo 1.83.0 on Gentoo linux with kernel 6.11.5 I get the following errors building NihAV. I got these before but had patched the code just enough so it would compile, but thought I’d share the errors:
error: this operation will panic at runtime
–> /var/tmp/portage/media-video/nihav-0.1.0_p20250410/work/nihav/nihav-qt/src/codecs/qcelp.rs:274:17
|
274 | self.lsp_data[5] = br.read(1)? as usize;
| ^^^^^^^^^^^^^^^^ index out of bounds: the length is 5 but the index is 5
|
= note: `#[deny(unconditional_panic)]` on by default
error: this operation will panic at runtime
–> /var/tmp/portage/media-video/nihav-0.1.0_p20250410/work/nihav/nihav-qt/src/codecs/qcelp.rs:276:17
|
276 | self.lsp_data[6] = br.read(1)? as usize;
| ^^^^^^^^^^^^^^^^ index out of bounds: the length is 5 but the index is 6
error: this operation will panic at runtime
–> /var/tmp/portage/media-video/nihav-0.1.0_p20250410/work/nihav/nihav-qt/src/codecs/qcelp.rs:277:17
|
277 | self.lsp_data[7] = br.read(1)? as usize;
| ^^^^^^^^^^^^^^^^ index out of bounds: the length is 5 but the index is 7
error: this operation will panic at runtime
–> /var/tmp/portage/media-video/nihav-0.1.0_p20250410/work/nihav/nihav-qt/src/codecs/qcelp.rs:278:17
|
278 | self.lsp_data[8] = br.read(1)? as usize;
| ^^^^^^^^^^^^^^^^ index out of bounds: the length is 5 but the index is 8
error: this operation will panic at runtime
–> /var/tmp/portage/media-video/nihav-0.1.0_p20250410/work/nihav/nihav-qt/src/codecs/qcelp.rs:280:17
|
280 | self.lsp_data[9] = br.read(1)? as usize;
| ^^^^^^^^^^^^^^^^ index out of bounds: the length is 5 but the index is 9
error: avoid using labels containing only the digits `0` and `1` in inline assembly
–> /var/tmp/portage/media-video/nihav-0.1.0_p20250410/work/nihav/nihav-itu/src/codecs/h264/dsp/mod.rs:1034:14
|
1034 | “1:”,
| ^ use a different label that doesn’t start with `0` or `1`
|
= help: start numbering with `2` instead
= note: an LLVM bug makes these labels ambiguous with a binary literal number on x86
= note: see for more information
= note: `#[deny(binary_asm_labels)]` on by default
error: avoid using labels containing only the digits `0` and `1` in inline assembly
–> /var/tmp/portage/media-video/nihav-0.1.0_p20250410/work/nihav/nihav-itu/src/codecs/h264/cabac_coder.rs:190:18
|
190 | “1:”,
| ^ use a different label that doesn’t start with `0` or `1`
|
= help: start numbering with `2` instead
Thanks for the report, I’ll commit the fixes tonight.
P.S. It’s strange with the labels in assembly, I remember that bit about the labels and IIRC even older rustc than I use made it an error but I somehow ended up with the version that does not care…