[ffmpeg] multimedia conversion utility

[/df]

The ffmpeg package has never had its own thread. It's mostly deployed as a utility by other user-facing packages. I believe these are the ones that may use it directly:

        webif 1.4.8-10  depends on ffmpeg (>= 2.8)
        soundout 0.1a   depends on ffmpeg
        thumbnails 1.0.4        depends on webif (>= 1.4.0-18)
        detectads 0.2.5-4       depends on webif (>= 1.4.0)
        youtube-dl 2020.09.20-2 depends on ffmpeg (>= 4.1)

Around here is discussion of the latest version at this writing.

 

[/df]

There's no libx264 encoder in the 2.8 or 4.1 builds, although H.264 and H.265 are supported for decoding.

Would it bloat the package beyond usability to include H.264 encoding, or would the relevant codec perform significantly worse than the already available mpeg2video, mpeg4, etc?

 

[Black Hole]

Would it bloat the package beyond usability to include H.264 encoding, or would the relevant codec perform significantly worse than the already available mpeg2video, mpeg4, etc?

I'm not aware we attempt any video encoding with the limited horsepower available, so what's the point?

 

[/df]

In which case why are the other video encoders available?

Actually, some sites are offering H.265/HEVC in mp4 containers and rather than having to copy files around the network, or using ffmpeg across NFS, it might be convenient just to set a long-running conversion on the HD/R to make such a file playable. It seems to run at about 0.5 real-time in a script piping a file over NFS, converting on a Core 2 Duo T7700 with no HW acceleration. I guess this would be an order of magnitude slower on the BCM7405 MIPS CPUs without access to the AV coprocessor.

 

[Black Hole]

In which case why are the other video encoders available?

Just because they're there, maybe, and it's easier to leave them in than take them out? Have you actually tried using one?

it might be convenient just to set a long-running conversion on the HD/R

Don't you think memory (even with a swap file) would be a limitation?

I guess this would be an order of magnitude slower on the BCM7405 MIPS CPUs without access to the AV coprocessor.

Does the AV pipeline even contain a hardware video encoder?

 

[/df]

Just because they're there, maybe, and it's easier to leave them in than take them out? Have you actually tried using one?

Yes, and I believe you replied to the post where I described doing so (but of course it's now lost in the forum somewhere).

...
Does the AV pipeline even contain a hardware video encoder?

Good point; I don't think it does, at least not for H.264 or similar, because that's always delivered in the broadcast stream. The preliminary spec talks about (IIRC) putting encoded frames in the AV memory and getting decoded pictures back.