And an mp4

[dericed]

a draft towards resolving https://github.com/amiaopensource/vrecord/issues/181. I'd rather not make a ton of options for the second mp4, but gather some consensus on a set of encoding options. Currently I just added -movflags write_colr+faststart -crf 21 -pix_fmt yuv420p -c:v libx264 -c:a aac but could mimic the audio mapping of the main output and maybe add some metadata.

I treated the mp4 output as a sidecar file so the option to enable it is at

[retokromer]

-movflags write_colr+faststart -crf 21 -pix_fmt yuv420p -c:v libx264 -c:a aac -b:a 160000 -ar 48000 -vf yadif,setdar=4/3

Maybe idet,bwdif rather than yadif?

[iamdamosuzuki]

@retokromer I'm mostly ambivalent to the deinterlacing method. What's the advantage to idet and bwdif in your opinion?

[retokromer]

@iamdamosuzuki bwdif has been improved quite a lot and we consider it today better than yadif. We switched to it for regular production a few months ago.

Some info are given also in ffmprovisir: discussion and commit.

[dericed]

I'm hesitant. @retokromer's proposal of idet,bwdif benches to average twice the processor time as just yadif. As this is an extra to a process where we want to prioritize the preservation file, I'm worried about a lot of time/processing energy to the mp4.

[retokromer]

I fully agree with @dericed that we want to prioritise the preservation file.

Most probably the MP4 access file would be better with idet,bwdif rather than yadif, but of course it requires more computing power (quality doesn’t come for free).

[iamdamosuzuki]

I didn't realize that idet,bwdif use far more computer power. I think yadif would be perfectly fine.

[iamdamosuzuki]

Just following up on this. I think it's perfectly fine to use bwdif for interlacement. There's no reason to use idet since we can assume that tape-based content will be interlaced. The exceedingly rare cases that aren't can be dealt with in some other way.

I would also like to suggest that a checkbox for "deinterlace access file" be added to the same "sidecar" files section. If that's too much for now it can be left off, but in that case the default should be to deinterlace the files.

[dericed]

Heya, rather than hardcode a custom filterchain for mp4s, I added an option like this:

[iamdamosuzuki]

I tested it out and noticed two issues:

1. The MP4 is being made in the Aux Files folder, not the same folder as the .mkv file
2. Unrelated, but setting the interlacing mode to "audio" brings up the error: WARNING: The configuration ignores the interlacement of the input and forces it to auto. Set to 'auto' if you prefer to keep the interlacement as the device describes it. I assume this is only supposed to show up if bff is selected

I will now try running a really long capture and see how it fares.

[iamdamosuzuki]

I made a 90 minute file. Everything appears to be good but there were some strange errors in the ffmpeg output.

[matroska @ 0x7fe510804e40] Insufficient space reserved for Cues: 1000000 < 3557641. No Cues will be output.
Error writing trailer of /Volumes/CaptureDisk/TestCaptures/MP4_Test_03_ffv1.mkv: Invalid argument
[mp4 @ 0x7fe510907540] Starting second pass: moving the moov atom to the beginning of the file
no ICC profile found, will write nclx/nclc colour info instead
    Last message repeated 2 times

See attached file: MP4_Test_03_ffv1_vrecord_input.log

[dericed]

Oh, that's not good, thanks for finding that. I was starting to pad some space at the beginning of the matroska for tags cuz exiftool and mkvinfo, under default settings, only read the tags before the first cluster. Maybe I'll up the amount of reserved space. Could you run mediaconch -mt MP4_Test_03_ffv1.mkv and let me know if the tags ended up before the first Cluster?

[dericed]

I haven't looked into the no ICC profile found, will write nclx/nclc colour info instead, can you start an issue on it.

[iamdamosuzuki]

The MP4 is looking good but there's a number of errors being reported by FFmpeg. I thought the last log I sent had them, but for some reason it didn't. Here's a copy/paste from terminal with all the errors/warnings related to the x264 encoding:

2024_06_20_Test01_ffv1_errors.txt

[dericed]

I think I addressed all remaining issues in the last three commits. @privatezero can you look at my approach in https://github.com/amiaopensource/vrecord/pull/800/commits/e3f555df9f125d6df404ddb660eee446caca1f6f in particular. This is because some options apply to all video outputs and some only to the preservation output.

[iamdamosuzuki]

Nearly everything looks good, but I'm still getting these weird errors when the recording stops:

[Parsed_drawtext_30 @ 0x7fd525145f00] Stray % near '  0.8%  1.2% 90.9%
[libx264 @ 0x7fa11190c880] mb I  I16..4: 10.0% 65.1% 24.8%
[libx264 @ 0x7fa11190c880] mb P  I16..4:  1.6%  6.6%  1.9%  P16..4: 42.5% 18.1% 11.2%  0.0%  0.0%    skip:18.1%
[libx264 @ 0x7fa11190c880] mb B  I16..4:  0.2%  0.6%  0.2%  B16..8: 44.6%  5.4%  1.2%  direct: 3.9%  skip:43.9%  L0:42.1% L1:49.8% BI: 8.1%
[libx264 @ 0x7fa11190c880] 8x8 transform intra:64.8% inter:77.2%
[libx264 @ 0x7fa11190c880] coded y,uvDC,uvAC intra: 71.9% 79.6% 34.1% inter: 20.9% 32.5% 1.2%
[libx264 @ 0x7fa11190c880] i16 v,h,dc,p: 40% 21%  2% 36%
[libx264 @ 0x7fa11190c880] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 17% 15%  6%  8%  9%  9%  8%  8%
[libx264 @ 0x7fa11190c880] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 24% 11%  5%  8%  7%  9%  5%  6%
[libx264 @ 0x7fa11190c880] i8c dc,h,v,p: 45% 21% 22% 12%
[libx264 @ 0x7fa11190c880] Weighted P-Frames: Y:4.0% UV:2.1%
[libx264 @ 0x7fa11190c880] ref P L0: 52.9% 13.1% 24.5%  9.3%  0.2%
[libx264 @ 0x7fa11190c880] ref B L0: 86.4% 10.4%  3.2%
[libx264 @ 0x7fa11190c880] ref B L1: 95.4%  4.6%
[libx264 @ 0x7fa11190c880] kb/s:1309.42
[aac @ 0x7fa11190de40] Qavg: 1025.709'
[Parsed_drawtext_30 @ 0x7fd525145f00] Stray % near '  0.8%  1.2% 90.9%
[libx264 @ 0x7fa11190c880] mb I  I16..4: 10.0% 65.1% 24.8%
[libx264 @ 0x7fa11190c880] mb P  I16..4:  1.6%  6.6%  1.9%  P16..4: 42.5% 18.1% 11.2%  0.0%  0.0%    skip:18.1%
[libx264 @ 0x7fa11190c880] mb B  I16..4:  0.2%  0.6%  0.2%  B16..8: 44.6%  5.4%  1.2%  direct: 3.9%  skip:43.9%  L0:42.1% L1:49.8% BI: 8.1%
[libx264 @ 0x7fa11190c880] 8x8 transform intra:64.8% inter:77.2%
[libx264 @ 0x7fa11190c880] coded y,uvDC,uvAC intra: 71.9% 79.6% 34.1% inter: 20.9% 32.5% 1.2%
[libx264 @ 0x7fa11190c880] i16 v,h,dc,p: 40% 21%  2% 36%
[libx264 @ 0x7fa11190c880] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 17% 15%  6%  8%  9%  9%  8%  8%
[libx264 @ 0x7fa11190c880] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 24% 11%  5%  8%  7%  9%  5%  6%
[libx264 @ 0x7fa11190c880] i8c dc,h,v,p: 45% 21% 22% 12%
[libx264 @ 0x7fa11190c880] Weighted P-Frames: Y:4.0% UV:2.1%
[libx264 @ 0x7fa11190c880] ref P L0: 52.9% 13.1% 24.5%  9.3%  0.2%
[libx264 @ 0x7fa11190c880] ref B L0: 86.4% 10.4%  3.2%
[libx264 @ 0x7fa11190c880] ref B L1: 95.4%  4.6%
[libx264 @ 0x7fa11190c880] kb/s:1309.42
[aac @ 0x7fa11190de40] Qavg: 1025.709'
    Last message repeated 1 times
[Parsed_drawtext_30 @ 0x7fd525145f00] Stray % near '  0.8%  1.2% 90.9%
[libx264 @ 0x7fa11190c880] mb I  I16..4: 10.0% 65.1% 24.8%
[libx264 @ 0x7fa11190c880] mb P  I16..4:  1.6%  6.6%  1.9%  P16..4: 42.5% 18.1% 11.2%  0.0%  0.0%    skip:18.1%
[libx264 @ 0x7fa11190c880] mb B  I16..4:  0.2%  0.6%  0.2%  B16..8: 44.6%  5.4%  1.2%  direct: 3.9%  skip:43.9%  L0:42.1% L1:49.8% BI: 8.1%
[libx264 @ 0x7fa11190c880] 8x8 transform intra:64.8% inter:77.2%
[libx264 @ 0x7fa11190c880] coded y,uvDC,uvAC intra: 71.9% 79.6% 34.1% inter: 20.9% 32.5% 1.2%
[libx264 @ 0x7fa11190c880] i16 v,h,dc,p: 40% 21%  2% 36%
[libx264 @ 0x7fa11190c880] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 17% 15%  6%  8%  9%  9%  8%  8%
[libx264 @ 0x7fa11190c880] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 24% 11%  5%  8%  7%  9%  5%  6%
[libx264 @ 0x7fa11190c880] i8c dc,h,v,p: 45% 21% 22% 12%
[libx264 @ 0x7fa11190c880] Weighted P-Frames: Y:4.0% UV:2.1%
[libx264 @ 0x7fa11190c880] ref P L0: 52.9% 13.1% 24.5%  9.3%  0.2%
[libx264 @ 0x7fa11190c880] ref B L0: 86.4% 10.4%  3.2%
[libx264 @ 0x7fa11190c880] ref B L1: 95.4%  4.6%
[libx264 @ 0x7fa11190c880] kb/s:1309.42
[aac @ 0x7fa11190de40] Qavg: 1025.709'

Besides that all is good.

[dericed]

These aren't errors but informational output from the libx264 and aac encoders.

[iamdamosuzuki]

ah ok. They're in red text :/

[iamdamosuzuki]

Also, that info isn't make it into the log. Is there maybe an issue where the x264 stderr isn't being sent to the log?