Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
18th September 2009, 16:33 | #22 | Link |
Video compressionist
Join Date: Jun 2009
Location: Israel
Posts: 126
|
My replay actually concerns the following your statement:
"If you can play the CAVLC version in realtime (otherwise you wouldn't be converting), then the CABAC version can't be more than 30% slower than realtime." So, the purpose of CABAC->CAVLC converter is to enable real-time playback on low performance decoder. Let's suppose that the decoder is enough powerful to playback CABAC mode. As I wrote earlier CABAC encoding/decoding might cause performance peaks which in turn can cause the decoder to drop pictures (i.e. cause jitter). To avoid jitter effects resulted by CABAC decoding perfromance peaks it is required a particular tool which would convert performance-problematic pictures into CAVLC mode. Frankly speaking some encoders use the above trick: if due to performance peaks real-time encoding is problematic then the encoder switches to CAVLC mode. |
18th September 2009, 20:13 | #23 | Link |
x264aholic
Join Date: Jul 2007
Location: New York
Posts: 1,752
|
What do you mean encoding/decoding would cause peaks that would cause the decoder to drop pictures?
All you're doing is decoding a CABAC (or CAVLC) stream, converting it to CAVLC (or CABAC) and saving it to a file. It'll go as fast as it can, and in doing so it won't "drop" a picture. If a particular frame takes a while to decode, then it just means the encoding stage won't be run until it receives a frame. But that doesn't mean the frame will be dropped at all. If you mean the converter selectively converts frames that tend to take more decoding time than others, then yes this would be useful. I didn't know hybrid CABAC/CAVLC streams were possible though. You'd need to write a tool to measure the peak bitrate a given computer can handle, and then build in an extra 10 - 20% CPU usage since it's not guaranteed the decoder will get 100% CPU usage.
__________________
You can't call your encoding speed slow until you start measuring in seconds per frame. |
19th September 2009, 14:36 | #24 | Link | |
Video compressionist
Join Date: Jun 2009
Location: Israel
Posts: 126
|
Quote:
For a CABAC coded stream the converter should estimate the decoding time per picture and if the estimated value exceeds a pre-defined threshold then the converter should re-encode the picture in CAVLC mode (even if the switch to CAVLC mode might result more bit-rate). Otherwise if a decoder can't decode a frame during 1/frame_rate seconds it might make the decoder to drop the picture. |
|
29th September 2009, 23:50 | #29 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Hardware players either don't support CABAC at all (Baseline and AppleTV), or have the hardware horsepower to handle CABAC for all supported profiles/levels. This is only something that would matter for software playback.
Of course, CABAC is only one part of performance on low-end machines. The bigger issue is really too high peak bitrates (which make CABAC and the rest of the decode slower). For higher bitrate content, it's useful to think about the lowest bitrate you want to support, and constrain the peak buffer to something that works on those devices. There's a whole lot of encodes out there with effectively unconstrained peaks, which seems like overkill for me. For most film content at a reasonable bitrate, a peak 1.5x the ABR really provides most of the value of VBR. |
30th September 2009, 19:07 | #31 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
That's an excellent example of what would be excluded from "most" . That definitily gave us some angina doing the Sopranos and Band of Brothers HD DVDs with very early versions of PEP.
That said, encoding content without peak constraints that included a meaningful percentage of that kind of pathological content could lead to visible quality reductions in the show itself. It's sometimes better to let some reallly hard but nonessential parts wind up looking not so great in order to preserve enough bits for the easier to encode and more. |
24th July 2012, 12:32 | #32 | Link |
Registered User
Join Date: Apr 2006
Posts: 137
|
Does a converter for CAVLC-CABAC exist yet? I could only google a plan to write one.
|
24th July 2012, 12:47 | #33 | Link |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
please note that this thread is from 2005.
if, in the intervening seven years since this thread was posted, you haven't taken the chance to upgrade your stone age computer to something that can decode 1080p h264 in software, maybe you should rethink your priorities. (to actually answer the question: no, as far as I know, no such thing exists. there's really no reason to use CAVLC at all anymore, even the smallest plastic toys support CABAC via hardware decoding these days.) |
24th July 2012, 15:31 | #34 | Link | |
Registered User
Join Date: Nov 2003
Location: San Diego, CA
Posts: 325
|
Quote:
I have since gone through 5 new computers, all of which were capable of decoding any file I throw at them. As TheFluff said, CAVLC is simply not useful.
__________________
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel, H2G2 |
|
24th November 2022, 11:04 | #35 | Link |
Huba Huba
Join Date: Aug 2005
Location: Palumbian Jungle
Posts: 78
|
I am aware that the pole caps have melted since this thread was started, but apart from getting flamed there might be no harm in asking:
Did some AVC CAVLC => CABAC converter appear over the last decades? I've got some CAVLC files with such a low bitrate that re-encoding evan with a modern codec like AV1 doesn't make sense - but at least I'd like to archive them with CABAC.
__________________
"The innocent have nothing to fear" :stupid: |
1st December 2022, 01:45 | #37 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
It could help with Xbox 360, which didn't have any hardware decoders. I was working on the Microsoft codec team when the H.264 software decoder was being built for HD DVD playback. Lots of very smart people using some very clever design using all three of the PowerPC + AltiVec cores and the GPU of the 360 were able to support ~30 Mbps 1080i30 H.264 playback for HD-DVD, including CABAC. The Silverlight-derived Greenlight framework's H.264 decoder could handle 1080p30 10 Mbps with CABAC just fine.
(Graybeard esoterica warning) Greenlight was only limited to 720p due to non-conformant H.264 files that were flagged Level 4.0 but had >>4 reference frames. It was x264's fault by not enforcing of profile and level constraints, so x265 --preset veryslow --level 4.0 would blithly make something that would require level 4.2 or higher. Even then the problem was with memory, not compute. It's still hard to believe that the 360 and PS3 only had 512 MB of RAM). Xbox One had a hardware H.264 Blu-ray compatible H.264 decoder, so shouldn't have been an issue. And even with software decoding, a single one of its six x64 cores would be able to do quite a lot of CABAC decode. |
Thread Tools | Search this Thread |
Display Modes | |
|
|