Sure you can. Install VLC on your phone and you'll be able to play the AV1 videos. Even the iPhone 7 released in 2016 can play AV1 video.
Don't agonise over battery life. The dav1d decoder for AV1 is great:
https://www.reddit.com/r/AV1/comments/1cf7eti/av1_dav1d_play...
https://www.reddit.com/r/AV1/comments/1cg2wv4/dav1d_battery_...
https://www.reddit.com/r/AV1/comments/1cgyace/dav1d_battery_...
https://www.reddit.com/r/AV1/comments/1chpz2r/dav1d_battery_...
This is by design, so that even extremely dated smart tvs and etc can also benefit from the bandwidth savings.
Fun fact: I can't say which, but some of the oldest devices (smart tvs, home security products, etc) work around their dated hardware decoders by buzzsawing 4k video in half, running each piece through the decoder at a resolution it supports, then stitching them back together.
av1_videos = {
p
for p in glob.glob("**/*.mp4", recursive=True)
if is_av1_video(p)
}
assert av1_videos == set()
Building a set just to check if it's empty is a bit more complexity than necessary. A more direct way that also bails out early: assert not any(is_av1_video(p) for p in glob.glob("**/*.mp4", recursive=True))
Equivalently (de Morgan's law): assert all(not is_av1_video(p) for p in glob.glob("**/*.mp4", recursive=True))If it bails out early it is of no use to them.
> This means that if the test fails, I can see all the affected videos at once. If the test failed on the first AV1 video, I’d only know about one video at a time, which would slow me down.
ffpj() { for f in "$@"; do ffprobe -v quiet -print_format json -show_format -show_streams "$f"; done }
Yes, ffprobe and mediainfo are the two common tools for this. This just feels like something that belongs as the answer to an everyday StackOverflow question. I don't understand what it's doing on the front page of HN.
Also, given that these videos are going to be reencoded, which is tremendously expensive, I feel that any optimization in this step is basically premature. Naively launching ffprobe 10,000 times is probably still less heavyweight than 1 reencode.
Right click on a YouTube video and select "Stats for Nerds" to see which format it's using in your browser. AV1 will be something like "av01.0.09M.08".
You've probably watched a lot of AV1 video without realising it.
I'm not sure it's fair to call reencodes expensive. Sure, its relatively expensive to using ffprobe, but any 4 series nvidia gpu with 2 nvenc engines can handle five? simultaneous realtime encodes, or will get up to near 180fps if it isn't being streamed. Our "we have aja at home" box with four of them churned through something like 20,000 hours of video in just under two weeks.
The PSNR/bitrate is much lower for HW encode, but the encode rate is typically realtime or better. That's a great tradeoff if you are transcoding so that a device with limited bandwidth can receive the video while streaming, or so that you can encode a raw livestream from a video capture or camera. It's not so great if you are saving to disk and planning to watch multiple times.
> This is shorter than the ffprobe code, and faster too – testing locally, this is about 3.5× faster than spawning an ffprobe process per file.
And the calls to the MediaInfo wrapper are not really harder to parallelize. `subprocess.check_output` is synchronous, so that code would have to be adapted to spawn in a loop and then collect the results in a queue or something. With the wrapper you basically end up doing the same thing, but with `multiprocessing` instead. And you can then just reuse a few worker processes for the entire job.
Off the top of my head, it's probably in the container metadata, so you'd just need libavformat and not even libavcodec. Pass it a path, open it, scan the list of streams and check the codec magic number?