rocky1410 wrote: ↑
Wed Dec 19, 2018 9:11 pm
it works perfect
I'm glad to hear my script successfully built FFmpeg and mpv!
rocky1410 wrote: ↑
Wed Dec 19, 2018 9:11 pm
works perfect – but when I add the --start=30 option, I get "Error while decoding frame!" and dropped frames increasing continuously...
Three little letters give me a giant clue that you're attempting to play a "non-standard" video.
I say this for one simple reason – your video ends with the MKV extension!
For those that may not be familiar with MKV, it stands for the Matroska Multimedia Container.
To be clear, I'm not suggesting you're doing anything "wrong" – but you're certainly dealing with a "non-standard" video. So I'm not surprised it's behaving in a manner that doesn't entirely live up to your expectations.
Now before anyone thinks I don't know what I'm talking about, let me go on the record by making this seemingly contradictory statement:
The MKV container is AWESOME
for several reasons. For one thing, it's a completely free and fully-open standard. Unlike almost all the other container standards out there – including MP4 – it's not "patent encumbered" or "proprietary" in any way. But more importantly, it's EXTREMELY FLEXIBLE
. That's because you can put almost any kind of video and audio encoding format inside it.
By contrast, the vastly more popular MP4 container is NOT
that flexible at all – especially by the standard of common, working implementations in the real world.
In theory, the MP4 container supports almost as many encoding formats as the MKV container. But the key phrase in my sentence is "in theory". As with many things, there's a big difference between theory and practice.
When I limit my analysis to (1) modern encoding formats that are (2) common on today's Internet, MP4s are virtually synonymous with only one kind of video encoding format – H.264. And when it comes to the audio encoding format you need to pair it with, you're limited to only 2 realistic choices – AAC or MP3. Again, I'm talking about "real-world common practice that works on almost all modern devices" – not what's theoretically possible on a nerd's computer.
Remember also that there's a GIANT elephant in the room that trumps everything else: Even if someone knows how to place an unconventional combination of encoding formats inside an MP4 container, what good is it if most media players, web browsers and software can't play it? I would argue it's NOT GOOD AT ALL. It's basically worthless.
So, back to MKV. I'm a big fan of it. In fact, in many of my personal experiments with FFmpeg, it's my "go-to" choice for my "internal" work flow.
Creating and processing a video is a multi-stage endeavor – but if you're not careful, each stage can degrade the quality of the source material. So if your goal is to maintain a "lossless pipeline" – 0% image degradation during each processing step – MKV is by far the best and most flexible choice available. [MKV is a completely agnostic container that will just as happily accept a "lossy" encoding, but that's not the point I'm trying to make right now.]
For example, I'll typically choose one of two lossless video encoders while the video is still "in the pipeline": libx264 in "crf 0" lossless quality mode OR
FFmpeg's built-in lossless encoder – FFV1. For audio, I'll typically choose the FLAC lossless encoder. The great part is that no matter what combination of encoders I choose, I can almost always drop them into the MKV container no matter what!
[My other favorite technique for a lossless pipeline is a frame-based image sequence approach – where I treat each frame of a video as a standalone image. For that, I use the inherently lossless PNG image format. But that's a topic for a different discussion.]
But here's the catch:
Everything I just said is great for "internal nerd use". But what about sharing the final video when all that internal processing is done? In other words, what modern format is best for "external" use? You know – actually sharing it with normal human beings that aren't FFmpeg nerds!
For that purpose, I would argue there's ONLY ONE LOGICAL CHOICE
in the entire media universe:
An MP4 container with 2 things inside it: An H.264-encoded video track and an AAC-encoded audio track.
It's the closest thing you can possibly get to a truly universal standard that almost anyone with a device made in the last 10 years can actually play! That's why, in my view, anyone who wishes to share a video with a general audience would have to be insane to pick any other container or codec pair. It's literally MP4 or it's cra*!
And like most modern devices today – including the Raspberry 1, 2 and 3 – there's a big added bonus for standard MP4 videos: Full support for GPU-based "hardware acceleration". That means that instead of your general-purpose CPU struggling to decode and play the computationally intensive MP4 "in software", you have the amazing power of the GPU doing all the heavy lifting "in hardware" – a chip that's specifically designed from the ground up to play the MP4 perfectly without dropping a single frame.
That's also why my tutorial – which I first published a year ago in December of 2017 – was so significant. Other than some partially-successful builds of VLC that were available at the time, I was the first person to bring a flawlessly-working modern media player to Raspbian Stretch – the Raspberry Pi's official operating system. That player, of course, is my customized build of mpv – a build that fully leverages the power of the Raspberry's GPU.
But like many devices today – when it comes to modern encoders – the Raspberry's built-in GPU support "only" extends to standard H.264-based videos. I say "only" in quotes because that makes it sound like some kind of big limitation. The reality is that it's no more "limited" than the United States dollar. When it comes to the idea of a "universal currency", does the dollar have some "limitations"? Of course it does! That's because there's no such thing as a truly universal currency. You can still find people around the world that won't accept the dollar. But that doesn't change the truth of my statement even slightly – the U.S. dollar is still, by far, the closest thing you'll find in the real world to a universal money standard. And it's no different with an MP4 – it's as close as it gets to a universal video standard. So the fact that the Raspberry supplies full-blown GPU-based hardware acceleration for MP4 video is, in fact, a very big deal.
Now, believe it or not, all of this seemingly academic background relates directly to your question. That's because it provides the necessary context to make the following bold statement:
Outside of "nerd world", no "normal" person who knows what they're doing would ever post or share a video inside an MKV container.
That by itself makes the video you're attempting to play highly "suspicious". By "suspicious", I mean there's a very good chance it doesn't contain an H.264-encoded video. If I had to wager, it probably contains a VP9-based video or maybe even an H.265 video. Or maybe it contains the brand-new AV1 codec. Whatever the case, if there isn't an H.264 video inside the MKV container, you have to realize that no matter how amazing a media player is, it's simply NOT going to provide any GPU acceleration on the Raspberry. That's not a limitation of mpv or any other player – it's simply a fundamental "limitation" of the Raspberry itself.
NOTE #1: I'm fully aware the Raspberry's GPU also supports acceleration for MPEG-2 and VC-1 codecs. But those ancient standards – which are not free and require the purchase of a license – are simply not relevant to my explanation.
NOTE #2: Could an MKV have an H.264 video track inside it? Absolutely! And if it does, my build of mpv – despite the video not being inside an MP4 container – is smart enough to still give it 100% hardware acceleration!
In fact, I sometimes encounter an H.264 video inside an MKV container when I download a music video with youtube-dl. Sometimes, I'll hand-pick the highest quality video track that's available – while ALSO
taking into account the "limitations" of the Raspberry's hardware. In other words, that means I'll pick a 1080p video track at 30 FPS that uses the "avc1" codec. [See my very detailed Appendix 2 for instructions on how to do this.] AVC1 – usually written in lower case by YouTube's servers – is just another name for H.264. So by picking an AVC1 / H.264, I'm guaranteeing that it will get full hardware support from the Raspberry's GPU. If I choose any other format – such as WebM / VP9 – there's no guarantee that it won't drop at least some frames. That's especially true if it's a 1080p video with a lot of motion and scene "complexity". Because if the GPU isn't helping out, it means all the heavy lifting is taking place inside the general-purpose CPU.
With a music video, I might also hand-pick the highest-quality audio track available. I might therefore choose an "opus @160k" audio track. But there's an issue with that: In most common implementations, an Opus-based audio track is NOT compatible with an H.264 / AVC1 video track! The solution? Youtube-dl, in conjunction with FFmpeg, automatically "merges" the 2 "incompatible" tracks by placing them inside an MKV container! So yeah, I have a few 1080p music videos as MKV files – with an unconventional H.264 / Opus codec pair inside. When I play it with my build of mpv, it provides an extremely high-quality experience!
An MKV like that works great on my Raspberry – because I get the best of both worlds: An H.264 video that plays perfectly on my GPU, along with the highest-quality audio track available. But again, if I ever intended to share that music video with a friend, I would certainly NOT pick that non-standard combination. Instead, I would pick the only combination that comes close to a truly universal standard: An H.264 / AVC1 video track + an AAC audio track that's wrapped inside an MP4 container!
NOTE #3: Despite the Raspberry not providing GPU support for other modern formats, my build of mpv still produces either perfect or near-perfect results for almost all 1080p videos – even without any assistance from the GPU. See my testing results section for more detail.
So a final "back to your question":
When dealing with an MKV container whose "video insides" are not "GPU-compatible" – especially if it also happens to be a 1080p – you're already pushing the Raspberry's CPU to its limits. But if you also force it to do "frame seeking" on top of that – like jumping ahead by an arbitrary amount of time – that certainly could push things over the edge. The CPU would already be straining, so any further "insult" could certainly make it even harder to keep up with the frames. Under those circumstances, the video could enter a point of no return – where the "drift" would keep accumulating and only get worse over time.
There's another possibility that has nothing to do with a "GPU-unfriendly" format choice – since I obviously don't know diddly about what's inside your MKV container: Some of your file's header data or timestamping could be damaged or missing. That would certainly throw things off. It might also explain why unmodified viewing works fine, but forcing it to seek forward to a specific time causes it to fall off a cliff.
So there ya go – I've covered all the bases in terms of what you're trying to do – and what your expectations should be.
But I'll go one even better!
Just in case this MKV video of yours is super important – for example, you're about to make a major presentation that finally unifies the General Theory of Relativity with the Standard Model – and you need your video to work flawlessly with full GPU support on the Raspberry – there's actually something very specific you can do with my build of FFmpeg. Just run the following command line in Terminal and it will take your MKV video – no matter what encoding technology it uses – and convert it into a perfectly standard and "visually lossless" MP4 video:
ffmpeg -i Nonstandard_Video.MKV -vf format=yuv420p -c:v libx264 -crf 18 -c:a libfdk_aac -b:a 128k Standard_Video.MP4
Is this command line or anything else in life guaranteed to work? Certainly not! If your MKV input video is sufficiently damaged, all bets are off. Nonetheless, especially since your video plays perfectly without seeking, it's got a great chance of doing exactly what you need.