Any interest in creating two outputs during capture?

[kieranjol]

I don't know enough about the bmdtools/ffmpeg pipeline, but it looks like combining the creation of a master file (ffv1/mkv) and a mezzanine (prores/mov) at the same time is doable? https://github.com/amiaopensource/vrecord/blob/master/vrecord#L1230

It looks as if adding, for example, -c:v prores -map 0 prores.mov to the final ffmpeg command could achieve this. I plan on testing this out when I get some time and access to a mac capture station, but I was just curious if this was the kind of thing where a patch might be welcome, or is it overkill when a subsequent transcode could just be performed? I'd imagine that finding space in the vrecord -e GUI might be trick as well.

I'm working with a colleague who needs a prores file for their exhibition workflow, but we need an FFV1/MKV file for our needs. I was going to just knock up a quick script, but I would like to pilot the use of vrecord in our workflow for this particular test.

[privatezero]

I know that @libbyhopfauf at Moving Image Preservation of Puget Sound (MIPoPS) was using a modified version of vrecord that created an h264 derivative on capture, so it definitely seems feasible (although I do recall prores being more intensive to encode so hopefully that wouldn't cause too much drag on the capture stream!)

[kieranjol]

Thanks @privatezero! I was actually thinking that proxy generation would also be interesting, but definitely not necessary for what I'm thinking of. I agree that the bottleneck could just be processing power.. I'll let ye know how the testing goes anyhow.

[retokromer]

Especially Kostya’s is slow.

[kieranjol]

Aye, but better for interlaced material?

[retokromer]

Better in general, except for speed…

[kieranjol]

A quick test worked just fine anyhow. System resources weren't an issue, though I didn't try prores_ks. I might look into this a bit more when I have some time and I might send in a pull request if I end up working on it. I think I can close this for now.

[bturkus]

very exciting!

[iamdamosuzuki]

This ticket was reopened with the hope that we could have simultaneous creation of different video formats when digitizing. The use case I'd like to suggest is the creation of an MP4 file concurrent with the creation of an FFV1/MKV file. Ideally I'd be nice to be able to create any combination of files concurrently, but creating MP4s concurrently will have the most utility for me personally :)

Here's some general attributes the MP4s should have

• video codec: libx264
• pixel format: yuv420p
• faststart enabled
• constant rate factor: 18 (or somewhere around there)
• audio codec: aac
• audio sample rate: 48kHz
• audio bitrate 160 kbps (or somewhere around there)
• frame size (option 1): Same as original
• frame size (option 2): 640x480 (perform necessary cropping for proper scaling)
• display aspect ratio: default 4:3 but it'd be nice to have the option for 16:9

The most problematic bits will be the frame size and display apsect ratio. For the frame size I suggest there be two options, keeping the original frame size or forcing 640x480. That will probably cover nearly all use cases, and anyone not covered can make adjustments as needed. Regarding DAR, a simple toggle switch for 16:9 would be sufficient to force a 16:9 DAR, and anything else can likely be defaulted to 4:3. Any outliers can be handled on a case-by-case basis.

[privatezero]

Just to play devil's advocate - aren't there some disadvantages to creating what I assume are access files at point of capture?

To do things like trim heads/tails, normalization of audio, application of deinterlacing filters etc. would still require additional manipulation that other software is more suited for.

I admit I am a bit of a fan of the 'Do one thing and do it well' philosophy, but isn't vrecord's strength more in capture of preservation files rather than other parts of the file processing chain?

[dericed]

@iamdamosuzuki can you review this issue. Anything left or can it be closed?

[iamdamosuzuki]

I'm very happy with the results of this! Right now it only creates MP4s, not ProRes as requested by @kieranjol but it meets the needs of LC.

@privatezero your comments are very thoughtful and certain are worth considering. I do think it's worthwhile to keep more intervention-heavy processes like trimming bars and normalizing to other software. However, as it stands the one-to-one MP4s that vrecord can create now are used by a lot of labs, and this will save a lot of time in post-processing.

[privatezero]

@iamdamosuzuki glad it's useful!