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.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 31st May 2014, 19:22   #81  |  Link
STaRGaZeR
4:2:0 hater
 
Join Date: Apr 2008
Posts: 1,302
Quote:
Originally Posted by mas_np View Post
Hi,
I am working on my thesis as implementation of intra-prediction by MATLAB for an image.
I am almost stuck in this thesis.
First of all I need a clear process of how to traverse the image in z-order scan. (how z-scan order really works)
Second I couldn't find so far a very clear description of intra-prediction algorithm.
May someone help me in this regard?
When you say "intra prediction", what kind do you need to implement? It's a very generic term. HEVC intra prediction is a lot more complex (and effective) than for example MPEG-2's. I did have to do intra prediction with MATLAB too, but it was very simple, only using DC mode, and I didn't have any problems implementing it. Don't ask me about it, I forgot everything about that horrible language
__________________
Specs, GTX970 - PLS 1440p@96Hz
Quote:
Originally Posted by Manao View Post
That way, you have xxxx[p|i]yyy, where xxxx is the vertical resolution, yyy is the temporal resolution, and 'i' says the image has been irremediably destroyed.
STaRGaZeR is offline   Reply With Quote
Old 6th September 2016, 08:55   #82  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,846
Could anyone please provide diagrams how to imagine motion search methods {dia|hex|umh|star|full}? The question came up which is more elaborate and comprehensive, but to explain why, one may need to see vector distribution diagrams on a coordinate system, I believe... I tried to use Google image search but could not find matching results. But I think to remember that I saw at least a diamond and a hexagonal motion search range once.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 27th November 2017, 19:21   #83  |  Link
sdancer75
Registered User
 
sdancer75's Avatar
 
Join Date: Jul 2013
Posts: 90
Very nice article ! Thanks
__________________
Just me...
sdancer75 is offline   Reply With Quote
Old 23rd April 2018, 16:02   #84  |  Link
sdancer75
Registered User
 
sdancer75's Avatar
 
Join Date: Jul 2013
Posts: 90
>>HEVC has two tools that are specifically designed to enable a multi-threaded decoder to decode a single picture with threads: Tiles and Wavefront.

The multi-threaded tools are ONLY for the decoding part ? As I can see inside the source code of the HM Test Software v16.x there is prediction also for the encoding part. Am I wrong ?
__________________
Just me...
sdancer75 is offline   Reply With Quote
Old 23rd April 2018, 16:50   #85  |  Link
pieter3d
Registered User
 
Join Date: Jan 2013
Location: Santa Clara CA
Posts: 114
Quote:
Originally Posted by sdancer75 View Post
The multi-threaded tools are ONLY for the decoding part ? As I can see inside the source code of the HM Test Software v16.x there is prediction also for the encoding part. Am I wrong ?
You're right, the encoder can take advantage of this tool too. But encoders could already do this in a way. For example in principle you could design your encoder with a separate motion search thread at every block.
pieter3d is offline   Reply With Quote
Old 23rd April 2018, 18:18   #86  |  Link
sdancer75
Registered User
 
sdancer75's Avatar
 
Join Date: Jul 2013
Posts: 90
Quote:
Originally Posted by pieter3d View Post
You're right, the encoder can take advantage of this tool too. But encoders could already do this in a way. For example in principle you could design your encoder with a separate motion search thread at every block.
@Pieter3d Thanx for the quick response. The real question for me as a researcher is that : The HM Test Software have a wavefront sync flag which means that it has already take into account this type of encoding.

So, in this case If I need to implement a parellelization code, I need to know if the previous line upper top CTU is encoded to start encoding the CTU in the next line. Is that implemented inside HM Software? If yes where specifically can I find this ?

I already checked the functions TEncSlice::encodeSlice(...) and TEndCu::xEncodeCU() and are seem that are the right candidates for parallel implementation. What do you think ?
__________________
Just me...
sdancer75 is offline   Reply With Quote
Old 23rd April 2018, 18:25   #87  |  Link
pieter3d
Registered User
 
Join Date: Jan 2013
Location: Santa Clara CA
Posts: 114
The HM reference software is not multi threaded, at least not when I last looked at it. So it doesn't specifically take advantage of it, but it does produce a stream that a decoder can decode with multiple threads.
The HM reference software is meant as just that, a reference. It makes no claim about being suitable for any kind of production setting. For example a production software encoder will almost certainly want to take advantage of this feature.
pieter3d is offline   Reply With Quote
Old 23rd April 2018, 18:46   #88  |  Link
sdancer75
Registered User
 
sdancer75's Avatar
 
Join Date: Jul 2013
Posts: 90
Quote:
Originally Posted by pieter3d View Post
The HM reference software is not multi threaded, at least not when I last looked at it. So it doesn't specifically take advantage of it, but it does produce a stream that a decoder can decode with multiple threads.
The HM reference software is meant as just that, a reference. It makes no claim about being suitable for any kind of production setting. For example a production software encoder will almost certainly want to take advantage of this feature.
Hi thank you for your comment. I know that the reference software is not for production settings but what I really want to know is if I want to use the wavefront (not in parallel) encoding do I have to implement by myself or is really exist inside the code ? Do you know that ?
__________________
Just me...
sdancer75 is offline   Reply With Quote
Old 23rd April 2018, 19:02   #89  |  Link
pieter3d
Registered User
 
Join Date: Jan 2013
Location: Santa Clara CA
Posts: 114
Quote:
Originally Posted by sdancer75 View Post
Hi thank you for your comment. I know that the reference software is not for production settings but what I really want to know is if I want to use the wavefront (not in parallel) encoding do I have to implement by myself or is really exist inside the code ? Do you know that ?
You can enable it in the HM encoder. It will insert the correct syntax and coding structure so that it matches the spec. It just doesn't actually run in a multi-threaded way.

The CABAC state update you can see here:
https://hevc.hhi.fraunhofer.de/trac/...lice.cpp#L1058

You can see the slice entry points inserted into the stream here:
https://hevc.hhi.fraunhofer.de/trac/...cGOP.cpp#L1755
pieter3d is offline   Reply With Quote
Old 23rd April 2018, 19:05   #90  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,846
WPP is the default parallelism mode in x265, and it runs multi-threaded.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 23rd April 2018, 22:04   #91  |  Link
sdancer75
Registered User
 
sdancer75's Avatar
 
Join Date: Jul 2013
Posts: 90
Quote:
Originally Posted by LigH View Post
WPP is the default parallelism mode in x265, and it runs multi-threaded.
Not in HM Test Software...
__________________
Just me...
sdancer75 is offline   Reply With Quote
Old 23rd April 2018, 22:10   #92  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,846
So is there any reason why you restrict yourself to the minimum reference implementation and avoid the practically usable and optimized implementation?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 23rd April 2018, 22:14   #93  |  Link
pieter3d
Registered User
 
Join Date: Jan 2013
Location: Santa Clara CA
Posts: 114
Quote:
Originally Posted by LigH View Post
So is there any reason why you restrict yourself to the minimum reference implementation and avoid the practically usable and optimized implementation?
It is not the JCT-VC group's goal to develop an encoder that is targeted to some production purpose. There are many ways that various companies and people want to use HEVC and they all have different design constraints. A highly optimized multi-threaded encoder for example is not appropriate for research or for hardware accelerator development.

The HM software is there as reference, an implementation that works and can demonstrate (nearly) all the features in the specification.
pieter3d is offline   Reply With Quote
Old 23rd April 2018, 22:16   #94  |  Link
sdancer75
Registered User
 
sdancer75's Avatar
 
Join Date: Jul 2013
Posts: 90
Quote:
Originally Posted by pieter3d View Post
You can enable it in the HM encoder. It will insert the correct syntax and coding structure so that it matches the spec. It just doesn't actually run in a multi-threaded way.

The CABAC state update you can see here:
https://hevc.hhi.fraunhofer.de/trac/...lice.cpp#L1058

You can see the slice entry points inserted into the stream here:
https://hevc.hhi.fraunhofer.de/trac/...cGOP.cpp#L1755
Hi

When wavefront is disabled the encoding is following the left to right and top to down (zig zag) scheme ? After a slice compression and encoding the data are send to cabac for each one of them one after the other ? In case the wavefront scheme is enabled (without multi threading) the encoding is the same zig zag (since no parallel lines are encoding at the same time)?
__________________
Just me...
sdancer75 is offline   Reply With Quote
Old 23rd April 2018, 22:22   #95  |  Link
pieter3d
Registered User
 
Join Date: Jan 2013
Location: Santa Clara CA
Posts: 114
Quote:
Originally Posted by sdancer75 View Post
Hi

When wavefront is disabled the encoding is following the left to right and top to down (zig zag) scheme ? After a slice compression and encoding the data are send to cabac for each one of them one after the other ? In case the wavefront scheme is enabled (without multi threading) the encoding is the same zig zag ?
The order of CTUs (64x64 blocks) is the same either case: left to right, top to bottom, also known as raster order (same as reading order).
The difference is in how the CABAC state is managed.
WPP off: CABAC state is reset at the start, and simply is updated as the encoder proceeds in raster order.
WPP on: The CABAC state is reset at the start of row 0 (same as before), but at the the start of every other row, the CABAC state is copied from the first CTU of the row above.

This means you can have a thread performing encode for each CTU row, as long as it starts after the row above has finished it's first CTU.
pieter3d is offline   Reply With Quote
Old 24th April 2018, 12:14   #96  |  Link
sdancer75
Registered User
 
sdancer75's Avatar
 
Join Date: Jul 2013
Posts: 90
Quote:
Originally Posted by pieter3d View Post
The order of CTUs (64x64 blocks) is the same either case: left to right, top to bottom, also known as raster order (same as reading order).
The difference is in how the CABAC state is managed.
WPP off: CABAC state is reset at the start, and simply is updated as the encoder proceeds in raster order.
WPP on: The CABAC state is reset at the start of row 0 (same as before), but at the the start of every other row, the CABAC state is copied from the first CTU of the row above.

This means you can have a thread performing encode for each CTU row, as long as it starts after the row above has finished it's first CTU.
Thank you for your responding.

So, If I want to use parallel wavefront encoding do I have to touch the CABAC code in the way it is written inside HM code ? My conclusions are that is not needed since the CABAC takes in mind the wavefront encoding and the only step is needed is the appropriate parallel synchronization of the shared data.
__________________
Just me...
sdancer75 is offline   Reply With Quote
Old 24th April 2018, 16:05   #97  |  Link
pieter3d
Registered User
 
Join Date: Jan 2013
Location: Santa Clara CA
Posts: 114
Are you writing your own encoder? Or using HM?
pieter3d is offline   Reply With Quote
Old 25th April 2018, 09:12   #98  |  Link
sdancer75
Registered User
 
sdancer75's Avatar
 
Join Date: Jul 2013
Posts: 90
Quote:
Originally Posted by pieter3d View Post
Are you writing your own encoder? Or using HM?
Hi,

No I am using HM Code and dont care about a production encoder just to make my own research about WPP. I want to adapt the implemented wavefront single threaded to multithreaded.
__________________
Just me...

Last edited by sdancer75; 25th April 2018 at 09:19.
sdancer75 is offline   Reply With Quote
Old 1st May 2018, 18:36   #99  |  Link
sdancer75
Registered User
 
sdancer75's Avatar
 
Join Date: Jul 2013
Posts: 90
@pieter3d Please clarify this to me.

In your very first post you say "HEVC supports four transform sizes: 4x4, 8x8, 16x16 and 32x32.", but inside "JCT-VC High Efficiency Video Coding (HEVC) Test Model 16 (HM 16) Improved Encoder Description" at Paragraph 4.2.5 Transform unit (TU) and transform tree structure it says "The transform unit (TU) is a square region of size 8x8, 16x16 or 32x32 luma samples/pixels defined by a quadtree partitioning of a leaf CU.".

From the specification I understand that there is no 4x4 size TU size. Is that correct ?

Another question is that Transform Units co-exist with Prediction Units inside a CU ? For example is the graph below correct ? The data are keeping TUs and PUs are luma and 2 chroma values ?

__________________
Just me...

Last edited by sdancer75; 1st May 2018 at 18:39.
sdancer75 is offline   Reply With Quote
Old 1st May 2018, 19:07   #100  |  Link
pieter3d
Registered User
 
Join Date: Jan 2013
Location: Santa Clara CA
Posts: 114
Quote:
Originally Posted by sdancer75 View Post
@pieter3d Please clarify this to me.

In your very first post you say "HEVC supports four transform sizes: 4x4, 8x8, 16x16 and 32x32.", but inside "JCT-VC High Efficiency Video Coding (HEVC) Test Model 16 (HM 16) Improved Encoder Description" at Paragraph 4.2.5 Transform unit (TU) and transform tree structure it says "The transform unit (TU) is a square region of size 8x8, 16x16 or 32x32 luma samples/pixels defined by a quadtree partitioning of a leaf CU.".

From the specification I understand that there is no 4x4 size TU size. Is that correct ?

Another question is that Transform Units co-exist with Prediction Units inside a CU ? For example is the graph below correct ? The data are keeping TUs and PUs are luma and 2 chroma values ?

Because the smallest CU is 8x8, there are four 4x4 transform units in a 2x2 arrangement when TX size is set to 4x4. There is never a single 4x4 transform by itself in a CU.

TUs and PUs only match size in intra blocks. For example inter blocks can have non-square PUs with various different sized TUs.
pieter3d is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 03:11.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.