5.5.2Main Profile
Some expressed opinions were tabulated as shown below to help organize the discussion of the issues.
Contrib
|
Tiles
|
WPP
|
Dep slices
|
ALF
|
LM chroma
|
NSQT
|
FGS
|
FR NB
|
Remove
|
|
|
|
|
|
|
KR NB
|
XOR WPP
|
XOR tiles
|
|
|
Add
|
|
|
UK NB
|
|
|
|
Don't add
|
Don't add
|
Don't add
|
|
J0125
|
Stronger remove
|
Remove
|
|
|
|
|
|
J0264
|
|
|
Add
|
|
|
|
|
J0289
|
Better than WPP
|
Semi-negative
|
|
|
|
|
|
J0307
|
|
|
|
Add
|
|
|
|
J0330
|
|
|
|
Add
|
|
|
|
Current
|
In
|
In
|
Out
|
Out
|
Out
|
Out
|
Out
|
Consensus
|
Don't remove
|
Don't remove
|
Add it
|
Don't add
|
Don't add
|
Don't add
|
Don't add
|
Decision: Add dependent slices to Main profile.
Decision: Remove ALF (incl. APS), LM chroma, NSQT, FGS from the text (on a best-effort basis within the time available).
In the discussion, it was suggested that dependent slices are especially relevant to WPP, so its consideration should take into account the decision on that feature. It was noted that dependent slices are very small feature from the decoder perspective. However, it was questioned whether it is really needed. It was asked why we need entry points encoded in the slice header instead of always using dependent slices. Participants responded that this would have a penalty of at least several bytes per entry point. Each dependent slice counts as a slice w.r.t. the limit on slices per picture.
Since their use is not required, the value of tile and WPP is limited to opportunistic (or negotiated) decoding use or the encoding perspective. Worst-case decode is not helped by inclusion of these features (without negotiation).
The ability to losslessly transcode a non-WPP bitstream to a WPP bitstream and vice versa was noted as an intresting capability, as described in J0032.
J0573 & J0575 new.
JCTVC-J0573 Tiles for the Main profile [M. Horowitz (eBrisk), J. Boyce (Vidyo), A. Fuldseth (Cisco), R. James (Altera), J. Sampedro (Polycom), A. Segall (Sharp), J. Sievers (LifeSize/Logitech), A. Wells (Ambarella), Y. Ye (InterDigital)] [late]
JCTVC-J0575 On WPP support in the Main profile [G. Clare, F. Henry, T. Leontaris, S. Worrall, J. Vieron, M. Raulet, P. Andrivon, D. Nicholson, X. Ducloux] [late]
Encoder-maker comment: Block-level interaction & MTU size matching in highly-parallel encoder favour tiles over WPP. Response on MTU matching, see F0335 which may indicate otherwise
Encoder-maker comment: Low-delay – desiring WPP with dependent slices.
Encoder-maker comment: Tiles preferred, less tight coupling of processes, efficient caching of reference data (greater overlap horizontally).
Encoder-maker comment: WPP already used in existing encoder, low-delay feasible, caching also feasible with appropriate use of slices – no problem today with AVC. Response: Do you need a normative tool then, if you're doing it with AVC without a problem? Reply: Yes, but prefer to have the feature available in the design, although possible to apply in non-normative fashion without that.
Encoder-maker comment: Software encoder – not sure how to use WPP for low-delay low bit-rate; but have a tile-based system already running.
It was commented that the decision on tiles & wavefronts is mostly a matter of coding efficiency. Another participant responded that the impact could be relatively severe, for example, F335 describes the coding efficiency impact of using slices as an alternative – with penalties sometimes in the 30-40% range.
JCTVC-J0578 Information on interpolation filters and ALF [I. S. Chong, M. Karczewicz] [late]
Dostları ilə paylaş: |
