So all of us who have Sony TVs have an issue that we can’t direct stream VC1 encoded video because of how sony has implemented VC1 codec (seems to be only provided via libstagefright and only then via their limited built in app that has bugs of its own). ffmpeg’s implementation is limited (not threaded to take advantage of our TVs multiple cores and not as optimized for ARM as it seems the x86 version is).
what this means is that software decoding VC1 on my sony tv is a case where it is very close to being able to do it, but falls a bit short (very choppy experience). If ffmpeg was improved to be able to do software decode of VC1 would the plex player choose to do it, or would it still insist that since there’s no VC1 MediaCodec that it won’t direct play it?
i.e. wondering the value of setting up a bounty for ffmpeg to improve its VC1 capabillities and how that would impact plex’s android player.
thanks.
Your TV does ZERO transcoding.
Your Server does ALL transcoding.
VC-1 is a PITA.
Most of us have a fair trial, followed closely by a speedy hangin’/picnic - when we encode it to ANYTHING else.
If you don’t want VC-1 to cause a transcoding issue (it will) fix it before it goes to the library - or buy a really big strong (single thead) horse in the CPU department 'cause you’re gonna need it.
transcoding it on the server isn’t a problem (it’s an 8 core xeon with 48GB of ram). I don’t want to transcode it on the TV either, I’d want to decode it (ala what it does with hevc, avc or anything else that it can hand off to a hardware decoder).
The question was, if there’s no hardware decoder, but the device has enough CPU power to decode it without extra hardware support, would plex ever do that, or would it just say I don’t care that you have enough cpu to decode it, I’m going to transcode it on the server. and send it in a format that tv has hardware support for.
Plex does do some software decoding. It depends on the codec. VC-1 is horrible for software decoding so it’s turned off.
There’s no way for the app to know this. It may work for very low bit rate files, but not higher ones. Or it might work in conjunction with 1 audio codec but not another. With something like VC1, there’s just too many things that can go wrong.
AFAIR, vc-1 is always single threaded, so it doesn’t particularly matter how many cores you have, it matters how fast a single core is.
vc-1 is an old old topic, just convert to x264 or x265 like everyone else, or don’t.
it’s your choice.
It is at my house.
8 cores down to 1 for a nice long Handbrake Job - but that’s the last time that’ll need to be done - so it’s worth it. Albeit painful.
I guess, to me it be nice if it was an option. primary reason is to avoid reduction in quality which is inherent with transcoding.
VC-1 will transcode on almost everything.
We know all about it.
You could sit through a LONG 265 Encode - Handbrake makes a nice one - if any of your stuff will play 265 - at 3750Kbps -and unless you can see the rings around Saturn, or count 14 Stars in The 7 Sisters - with the nekked eye - you won’t see the difference.
But you already said it doesn’t work well. Why would you want to keep trying?
i’m not sure vc-1 has to be single threaded. It’s single threaded in ffmpeg/libavcodec, that is true (i.e. the primary or perhaps only oss version of the codec). from what I understand, MSFT’s impleentation of it is multithreaded (which of course doesn’t help ffmpeg today, but if true, demonstrates that it could be implemented).
While I could transcode, I’m not willing to lower quality. I know my TV (i.e. ffmpeg cpu decoding) can’t keep up with the vc1 blurays today (i.e. vlc/kodi both struggle, its close, but not good enough.
it’s also going in the opposite direction of hardware. i.e. the raspberry pi 4 one no longer get with vc1 hardware decoding. Even with ffmpeg being single threaded, its getting to the point in a generation or two that i’d expect even the SOC’s in TVs to be able to cpu decode it without a problem.
To me it seems to make sense to allow cpu decoding. If I were implementing it I’d provide 3 settings. 1. Force Transcoding (i.e. current behavior) 2. smart (i.e. try to cpu play, but if drop frames, alert user and switch to transcoding) 3. force cpu play (i.e. what one might say today with kodi or vlc).
vc-1 is a dead codec so I would not expect much (if any) support, I also believe there are licensing considerations as well (which might be the main reason why little development for it has occurred anywhere).
But feel free to post an actual feature request for the above, I have zero control over their priorities, but I wish you the best of luck.
basically as time goes on we will see 2 trends
- codecs dropping out of hardware support
- cpu’s on playback devices getting stronger
it seems short sided to not have a cpu playback option.
this is an optimistic view.
chips may very well increase in processing, but… the majority of streaming devices are designed for very specific codecs and services (ie netflix etc), vc1 is not used extensively anywhere outside of bluray discs, which are not relevant to the manufactures building streaming hardware, at the lowest possible physical and engineering cost.
I’m not convinced licensing plays a role. i.e. the same patent issues that vc-1 has, also impacts h264 and h265 (i.e. the same patent licensing body licenses patents for all 3, MPEG LA)
VC-1 is a proprietary codec developed by Microsoft. The implementation in FFMPEG is a reverse engineered version. Due to how the decoder works, it can only do it single threaded. I believe anything else would be a violation of their patent. I wouldn’t expect any significant improvements in this.
Most SoC and standalone CPU or even GPU improvements are coming in the way of more cores. Improving single core performance is mostly a factor of speed and power. For low power devices like TV’s there is little motivation to improve the single core ability.
I seriously doubt there’s anything that prevents ffmpeg from being multithreaded except for someone implementing. digging through old stuff it seems it was a proposed Google Summer of Code project in 2011 to make VC1 multithreaded in ffmpeg. I’m guessing no one took it up. I might contact the mentors listed and asking if they would help guide me to do it. My C skills are a bit rusty as the past few years have been just doing Kubernetes code in go and I know minimal about codecs, but I’m always up for a challenge.
I think the benchmarks say, you’re wrong. My 2017 Sony (x940e) which can just not keep up in software decode is about half as powerful (per geekbench) in singlethreaded coded as the current generation soc sony uses
i.e.
https://browser.geekbench.com/v4/cpu/search?q=MT5891
vs
MT5893 - Geekbench Search - Geekbench.
I’d actually be interested in seeing if a modern sony tv could play a vc1 bluray with kodi or vlc (don’t have one, but would be interested in seeing)
btw, just for the record vc-1 is not anymore a proprietary codec than almost any other codec that one wants to use.
one can read the spec if they want: https://multimedia.cx/mirror/VC-1_Compressed_Video_Bitstream_Format_and_Decoding_Process.pdf
one can read the reference implementation: https://multimedia.cx/mirror/VC1_reference_decoder_release6.zip (strangely enough written by ARM under contract to Microsoft)
What?
I can’t hear ya over the CPU blower - I have a VC-1 job in Handbrake…
Good luck getting this all set up like you want it.
I’m watching this thread with great interest - while Handbrake is working - can’t wait to see what happens.
Maybe proprietary wasn’t the correct word. I’m not an expert on this stuff, but AFAIK, yes there is a way to write your own decoder following that document, similar to other codecs, but there are still patents and licensing fees may apply. One of the patents on the VC1 codec is on multi-threaded decoding which I believe is owned by Microsoft and they do require a license to use that, which is why I believe decoding of VC1 will not improve until Microsoft chooses to allow this without requiring a license.
I remember reading a discussion about this over in the FFMPEG forums some time ago. If this could have been done, it would have. There is no practical reason to limit this to a single core.
