Don't transcode h264 to ffv1 for preservation to avoid filesize panic #14
Conversation
normalization/preservation-ffv1.sh
Outdated
| @@ -6,7 +6,11 @@ audioCodec="pcm_s16le" | |||
| videoCodec="ffv1 -level 3" | |||
|
|
|||
| command="ffmpeg -vsync passthrough -i \"${inputFile}\" " | |||
| command="${command} -vcodec ${videoCodec} -g 1 " | |||
| if ffprobe $inputFile 2>&1 | grep "Video: h264"; then | |||
There was a problem hiding this comment.
Probably safer to quote "${inputFile}".
|
This may be overcomplicating things, since the goal here is a simple default, but I would consider limiting this to h264 yuv420p video, which I'm pretty sure is the most widely supported variant of h264 video. When I was working for a museum, I saw a lot of h264 video (created in-house) that used a chroma subsampling of 4:2:2, which doesn't seem as widely supported for playback as 4:2:0 h264 video. ffprobe characterized it as something like: We ultimately chose not to normalize this video format - or any video format - but someone wanting to normalize for preservation may want to distinguish this type of h264 from the more common types, as it will play back in fewer video rendering applications. At the time I tested it out using open source players on Linux, I was only able to play it back with ffmpeg and not with VLC. Newer versions of VLC may support it now. In my experience, the 4:2:2 h264 video was similar in size to 4:2:2 ProRes, so the size difference from ffv1 video is probably not as extreme as it is when normalizing from 4:2:0 h264. A second grep of the ffprobe output for "yuv420p" would limit the scope of this to just yuv420p video. |
|
@axfelix @andrewjbtw Hi both - this repo is no longer used (as per the README). The method for contributing code changes is documented here. |
I know this has been talked about a lot and there are probably more sophisticated ways of doing it, but here's a really simple proof of concept in case you're interested in using this as a default...