vrecord DV capture creates .movs that QuickTime Player cannot open

[tomackroyd]

I am using vrecord GUI to capture from DV tape. Selecting the option to record to .mov creates files that QuickTime Player cannot open: "The document “DV_TAPE_REUBEN_2022.mov” could not be opened. The file isn’t compatible with QuickTime Player." My current workaround is either to capture to .dv or use dvpackager -Z to re-containerise (and generate that extremely cool chapter marker file).

Here are logs for an example file, and MediaInfo metadata for the file and the "fixed" version DV_TAPE_REUBEN_2022_vrecord_input.log DV_TAPE_REUBEN_2022_capture_options.log DV_TAPE_REUBEN_2022_MediaInfo.txt DV_TAPE_REUBEN_2022_part1dvpackager-Z_MediaInfo.txt

Happy to say that I am not seeing vrecord drop frames as reported way back in https://github.com/mipops/dvrescue/issues/34 (dropped frames in the above log are due to record headclogs)

macOS Ventura 13.4.1 (c) Macbook Air M2 amiaopensource/amiaos/vrecord 2023-08-07

[tomackroyd]

Lightbulb. This may be me misunderstanding the interface. I think what's happening is - I select "QuickTime" as the destination format, and enter "file.mov" as the filename. But actually the "select format" is a dvpackager option only, for post processing. QuickTime does not recognise .dv files that have been incorrectly named .mov. Possible solution: make sure users understand vrecord will always digitise to .dv, and that it's only dvpackager that has .mov/.dv/.mkv options.

If I'm right, this issue can be closed. Tom

[privatezero]

Thanks for reporting @tomackroyd! That does seem like something that maybe the interface should make more clear to users. I'll leave this open until we've made some changes to address it.

[privatezero]

One more question - I'm on Linux, but in testing this, at least on my end, the DV window of the GUI already forces files to be captured with the .dv extension. On your system when in the DV window is it allowing you to manually delete the .dv and enter .mov in the Output Filename field?

[tomackroyd]

Well weirdly it's now not allowing me to do that either, so I have no idea how I ended up with .mov files. Will check again next time I have my deck connected.

[tomackroyd]

Have run vrecord again, confirm it creates a .mov not a .dv, though I'm fairly certain it's not a QuickTime file, it just has a .mov file extension. (MediaInfo reports "FileExtension_Invalid: dv dif") Also from the capture options log: "DV_CONTAINER_CHOICE: QuickTime"

QuickTime was specified for dvpackager post-capture, which created a genuine .mov

CHINA_TAPE_5_capture_options.log CHINA_TAPE_5_vrecord_input.log CHINA_TAPE_5.mov.dvrescue xml.txt CHINA_TAPE_5_MediaInfo.txt

[tomackroyd]

A quick test yesterday - selecting dv as dvpackager option leads to vrecord writing the capture to a true .dv file

[privatezero]

@tomackroyd thanks for confirming! I think I've spotted what is causing this - I have a branch that should address this - but will need to confirm that it is adhering to expected/desired behavior before merging.

@dericed thoughts on forcing dv output to .dv? All MKV/MOV wrapping was intended to be done through dvrescue...right?

[dericed]

The output of avfctl (or dvrescue) should be .dv and then repackaged into a container after capture (dvpackager). It's a challenge to capture directly to a container as dv on a tape can change characteristics midtape. FCP and other tools could do it but would need to stop the transfer at any transition.

[privatezero]

that's what I thought! I suspect that the _review_option function was overriding this - I added a line in https://github.com/amiaopensource/vrecord/pull/767 to force output extension to dv