What is `linesize` in LibAV
I am playing with video encoding using LibAV and unable to understand the purpose of linesize
.
For e.g., declaration of av_image_alloc
function in LibAV takes linesizes as arguments:
int av_image_alloc ( uint8_t * pointers[4],
int linesizes[4],
int w,
int h,
enum AVPixelFormat pix_fmt,
int align
)
I am new to LibAV and video encoding. Feel free to provide any link which can also give me little background of video encoding.
c++ libavcodec libav
add a comment |
I am playing with video encoding using LibAV and unable to understand the purpose of linesize
.
For e.g., declaration of av_image_alloc
function in LibAV takes linesizes as arguments:
int av_image_alloc ( uint8_t * pointers[4],
int linesizes[4],
int w,
int h,
enum AVPixelFormat pix_fmt,
int align
)
I am new to LibAV and video encoding. Feel free to provide any link which can also give me little background of video encoding.
c++ libavcodec libav
add a comment |
I am playing with video encoding using LibAV and unable to understand the purpose of linesize
.
For e.g., declaration of av_image_alloc
function in LibAV takes linesizes as arguments:
int av_image_alloc ( uint8_t * pointers[4],
int linesizes[4],
int w,
int h,
enum AVPixelFormat pix_fmt,
int align
)
I am new to LibAV and video encoding. Feel free to provide any link which can also give me little background of video encoding.
c++ libavcodec libav
I am playing with video encoding using LibAV and unable to understand the purpose of linesize
.
For e.g., declaration of av_image_alloc
function in LibAV takes linesizes as arguments:
int av_image_alloc ( uint8_t * pointers[4],
int linesizes[4],
int w,
int h,
enum AVPixelFormat pix_fmt,
int align
)
I am new to LibAV and video encoding. Feel free to provide any link which can also give me little background of video encoding.
c++ libavcodec libav
c++ libavcodec libav
asked Nov 12 '18 at 6:57
random_28random_28
728515
728515
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
linesize
is the width of your image in memory for each color channel. It may greater or equal to w
, for memory alignment issue.
Check ffmpeg av frame doc:
For video the linesizes should be multiples of the CPUs alignment preference, this is 16 or 32 for modern desktop CPUs. Some code requires such alignment other code can be slower without correct alignment, for yet other it makes no difference.
The linesize may be larger than the size of usable data – there may be extra padding present for performance reasons.
In case of RGB, linesize[0] will denote the size in bytes of each pixel for R color channel, linesize[1] will denote the size in bytes of each pixel for G color channel and so on right?
– random_28
Nov 12 '18 at 18:15
Quick Question, frame->data[0] contains the R channel and frame->data[1] contains G channel, right ?
– random_28
Nov 12 '18 at 18:26
@random_28 That would be true in case of planar RGB (such asAV_PIX_FMT_GBRP
), however typically libav uses packed RGB, solinesize[0]
will denote size in bytes for line in array ofRGBRGB...
bytes stored inpointers[0]
. seepixfmt.h
for the list of supported formats (which also explains how they are stored). Also note that this answer is rather misleading,linesize
can be smaller or larger thanw
depending on pixel format while alignment is actually optional.
– VTT
Nov 12 '18 at 18:36
@VTT So pointers[0] contains all theRGBRGB...
values. Then what are thepointers[1]
andpointers[2]
containing?
– random_28
Nov 12 '18 at 18:44
@random_28 nothing, they are supposed to be nulls when not used.
– VTT
Nov 12 '18 at 18:45
|
show 3 more comments
This function will allocate a buffer large enough to hold image data splitting it into one or more component arrays (planes). Depending on format, size of the line of the each picture component will have its own width (in bytes) (which may be much smaller or much larger than image width) and will also be padded to achieve the specified alignment (16 bytes typically to make vector instructions work). For example with typical YCbCr image with 4:2:0 subsampling there will be 3 planes (that is 3 non-null pointers stored in pointers
) and width of the luma plane line will be (padded) image width, width of the each chroma component lines will be (padded) half image width.
Also note that both pointers
and linesizes
in this function are out pointer parameters, not arrays.
It can’t be smaller than the width.
– szatmary
Nov 12 '18 at 14:09
@szatmary I've mentioned an example when line size is 2x smaller than image width
– VTT
Nov 12 '18 at 14:10
Fair enough. The first half just reads funny, because you must have the chroma plane at least width size.
– szatmary
Nov 12 '18 at 14:15
@szatmary Not really, chroma plane has 1/2 horizonal and vertical subsampling and each chroma line therefore is 2x smaller than image width...
– VTT
Nov 12 '18 at 14:18
I understand chroma sub sampling. On my first read of your response I felt it was less than clear. That’s ok if you disagree.
– szatmary
Nov 12 '18 at 14:27
|
show 5 more comments
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53257213%2fwhat-is-linesize-in-libav%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
linesize
is the width of your image in memory for each color channel. It may greater or equal to w
, for memory alignment issue.
Check ffmpeg av frame doc:
For video the linesizes should be multiples of the CPUs alignment preference, this is 16 or 32 for modern desktop CPUs. Some code requires such alignment other code can be slower without correct alignment, for yet other it makes no difference.
The linesize may be larger than the size of usable data – there may be extra padding present for performance reasons.
In case of RGB, linesize[0] will denote the size in bytes of each pixel for R color channel, linesize[1] will denote the size in bytes of each pixel for G color channel and so on right?
– random_28
Nov 12 '18 at 18:15
Quick Question, frame->data[0] contains the R channel and frame->data[1] contains G channel, right ?
– random_28
Nov 12 '18 at 18:26
@random_28 That would be true in case of planar RGB (such asAV_PIX_FMT_GBRP
), however typically libav uses packed RGB, solinesize[0]
will denote size in bytes for line in array ofRGBRGB...
bytes stored inpointers[0]
. seepixfmt.h
for the list of supported formats (which also explains how they are stored). Also note that this answer is rather misleading,linesize
can be smaller or larger thanw
depending on pixel format while alignment is actually optional.
– VTT
Nov 12 '18 at 18:36
@VTT So pointers[0] contains all theRGBRGB...
values. Then what are thepointers[1]
andpointers[2]
containing?
– random_28
Nov 12 '18 at 18:44
@random_28 nothing, they are supposed to be nulls when not used.
– VTT
Nov 12 '18 at 18:45
|
show 3 more comments
linesize
is the width of your image in memory for each color channel. It may greater or equal to w
, for memory alignment issue.
Check ffmpeg av frame doc:
For video the linesizes should be multiples of the CPUs alignment preference, this is 16 or 32 for modern desktop CPUs. Some code requires such alignment other code can be slower without correct alignment, for yet other it makes no difference.
The linesize may be larger than the size of usable data – there may be extra padding present for performance reasons.
In case of RGB, linesize[0] will denote the size in bytes of each pixel for R color channel, linesize[1] will denote the size in bytes of each pixel for G color channel and so on right?
– random_28
Nov 12 '18 at 18:15
Quick Question, frame->data[0] contains the R channel and frame->data[1] contains G channel, right ?
– random_28
Nov 12 '18 at 18:26
@random_28 That would be true in case of planar RGB (such asAV_PIX_FMT_GBRP
), however typically libav uses packed RGB, solinesize[0]
will denote size in bytes for line in array ofRGBRGB...
bytes stored inpointers[0]
. seepixfmt.h
for the list of supported formats (which also explains how they are stored). Also note that this answer is rather misleading,linesize
can be smaller or larger thanw
depending on pixel format while alignment is actually optional.
– VTT
Nov 12 '18 at 18:36
@VTT So pointers[0] contains all theRGBRGB...
values. Then what are thepointers[1]
andpointers[2]
containing?
– random_28
Nov 12 '18 at 18:44
@random_28 nothing, they are supposed to be nulls when not used.
– VTT
Nov 12 '18 at 18:45
|
show 3 more comments
linesize
is the width of your image in memory for each color channel. It may greater or equal to w
, for memory alignment issue.
Check ffmpeg av frame doc:
For video the linesizes should be multiples of the CPUs alignment preference, this is 16 or 32 for modern desktop CPUs. Some code requires such alignment other code can be slower without correct alignment, for yet other it makes no difference.
The linesize may be larger than the size of usable data – there may be extra padding present for performance reasons.
linesize
is the width of your image in memory for each color channel. It may greater or equal to w
, for memory alignment issue.
Check ffmpeg av frame doc:
For video the linesizes should be multiples of the CPUs alignment preference, this is 16 or 32 for modern desktop CPUs. Some code requires such alignment other code can be slower without correct alignment, for yet other it makes no difference.
The linesize may be larger than the size of usable data – there may be extra padding present for performance reasons.
answered Nov 12 '18 at 7:10
halfelfhalfelf
6,504103147
6,504103147
In case of RGB, linesize[0] will denote the size in bytes of each pixel for R color channel, linesize[1] will denote the size in bytes of each pixel for G color channel and so on right?
– random_28
Nov 12 '18 at 18:15
Quick Question, frame->data[0] contains the R channel and frame->data[1] contains G channel, right ?
– random_28
Nov 12 '18 at 18:26
@random_28 That would be true in case of planar RGB (such asAV_PIX_FMT_GBRP
), however typically libav uses packed RGB, solinesize[0]
will denote size in bytes for line in array ofRGBRGB...
bytes stored inpointers[0]
. seepixfmt.h
for the list of supported formats (which also explains how they are stored). Also note that this answer is rather misleading,linesize
can be smaller or larger thanw
depending on pixel format while alignment is actually optional.
– VTT
Nov 12 '18 at 18:36
@VTT So pointers[0] contains all theRGBRGB...
values. Then what are thepointers[1]
andpointers[2]
containing?
– random_28
Nov 12 '18 at 18:44
@random_28 nothing, they are supposed to be nulls when not used.
– VTT
Nov 12 '18 at 18:45
|
show 3 more comments
In case of RGB, linesize[0] will denote the size in bytes of each pixel for R color channel, linesize[1] will denote the size in bytes of each pixel for G color channel and so on right?
– random_28
Nov 12 '18 at 18:15
Quick Question, frame->data[0] contains the R channel and frame->data[1] contains G channel, right ?
– random_28
Nov 12 '18 at 18:26
@random_28 That would be true in case of planar RGB (such asAV_PIX_FMT_GBRP
), however typically libav uses packed RGB, solinesize[0]
will denote size in bytes for line in array ofRGBRGB...
bytes stored inpointers[0]
. seepixfmt.h
for the list of supported formats (which also explains how they are stored). Also note that this answer is rather misleading,linesize
can be smaller or larger thanw
depending on pixel format while alignment is actually optional.
– VTT
Nov 12 '18 at 18:36
@VTT So pointers[0] contains all theRGBRGB...
values. Then what are thepointers[1]
andpointers[2]
containing?
– random_28
Nov 12 '18 at 18:44
@random_28 nothing, they are supposed to be nulls when not used.
– VTT
Nov 12 '18 at 18:45
In case of RGB, linesize[0] will denote the size in bytes of each pixel for R color channel, linesize[1] will denote the size in bytes of each pixel for G color channel and so on right?
– random_28
Nov 12 '18 at 18:15
In case of RGB, linesize[0] will denote the size in bytes of each pixel for R color channel, linesize[1] will denote the size in bytes of each pixel for G color channel and so on right?
– random_28
Nov 12 '18 at 18:15
Quick Question, frame->data[0] contains the R channel and frame->data[1] contains G channel, right ?
– random_28
Nov 12 '18 at 18:26
Quick Question, frame->data[0] contains the R channel and frame->data[1] contains G channel, right ?
– random_28
Nov 12 '18 at 18:26
@random_28 That would be true in case of planar RGB (such as
AV_PIX_FMT_GBRP
), however typically libav uses packed RGB, so linesize[0]
will denote size in bytes for line in array of RGBRGB...
bytes stored in pointers[0]
. see pixfmt.h
for the list of supported formats (which also explains how they are stored). Also note that this answer is rather misleading, linesize
can be smaller or larger than w
depending on pixel format while alignment is actually optional.– VTT
Nov 12 '18 at 18:36
@random_28 That would be true in case of planar RGB (such as
AV_PIX_FMT_GBRP
), however typically libav uses packed RGB, so linesize[0]
will denote size in bytes for line in array of RGBRGB...
bytes stored in pointers[0]
. see pixfmt.h
for the list of supported formats (which also explains how they are stored). Also note that this answer is rather misleading, linesize
can be smaller or larger than w
depending on pixel format while alignment is actually optional.– VTT
Nov 12 '18 at 18:36
@VTT So pointers[0] contains all the
RGBRGB...
values. Then what are the pointers[1]
and pointers[2]
containing?– random_28
Nov 12 '18 at 18:44
@VTT So pointers[0] contains all the
RGBRGB...
values. Then what are the pointers[1]
and pointers[2]
containing?– random_28
Nov 12 '18 at 18:44
@random_28 nothing, they are supposed to be nulls when not used.
– VTT
Nov 12 '18 at 18:45
@random_28 nothing, they are supposed to be nulls when not used.
– VTT
Nov 12 '18 at 18:45
|
show 3 more comments
This function will allocate a buffer large enough to hold image data splitting it into one or more component arrays (planes). Depending on format, size of the line of the each picture component will have its own width (in bytes) (which may be much smaller or much larger than image width) and will also be padded to achieve the specified alignment (16 bytes typically to make vector instructions work). For example with typical YCbCr image with 4:2:0 subsampling there will be 3 planes (that is 3 non-null pointers stored in pointers
) and width of the luma plane line will be (padded) image width, width of the each chroma component lines will be (padded) half image width.
Also note that both pointers
and linesizes
in this function are out pointer parameters, not arrays.
It can’t be smaller than the width.
– szatmary
Nov 12 '18 at 14:09
@szatmary I've mentioned an example when line size is 2x smaller than image width
– VTT
Nov 12 '18 at 14:10
Fair enough. The first half just reads funny, because you must have the chroma plane at least width size.
– szatmary
Nov 12 '18 at 14:15
@szatmary Not really, chroma plane has 1/2 horizonal and vertical subsampling and each chroma line therefore is 2x smaller than image width...
– VTT
Nov 12 '18 at 14:18
I understand chroma sub sampling. On my first read of your response I felt it was less than clear. That’s ok if you disagree.
– szatmary
Nov 12 '18 at 14:27
|
show 5 more comments
This function will allocate a buffer large enough to hold image data splitting it into one or more component arrays (planes). Depending on format, size of the line of the each picture component will have its own width (in bytes) (which may be much smaller or much larger than image width) and will also be padded to achieve the specified alignment (16 bytes typically to make vector instructions work). For example with typical YCbCr image with 4:2:0 subsampling there will be 3 planes (that is 3 non-null pointers stored in pointers
) and width of the luma plane line will be (padded) image width, width of the each chroma component lines will be (padded) half image width.
Also note that both pointers
and linesizes
in this function are out pointer parameters, not arrays.
It can’t be smaller than the width.
– szatmary
Nov 12 '18 at 14:09
@szatmary I've mentioned an example when line size is 2x smaller than image width
– VTT
Nov 12 '18 at 14:10
Fair enough. The first half just reads funny, because you must have the chroma plane at least width size.
– szatmary
Nov 12 '18 at 14:15
@szatmary Not really, chroma plane has 1/2 horizonal and vertical subsampling and each chroma line therefore is 2x smaller than image width...
– VTT
Nov 12 '18 at 14:18
I understand chroma sub sampling. On my first read of your response I felt it was less than clear. That’s ok if you disagree.
– szatmary
Nov 12 '18 at 14:27
|
show 5 more comments
This function will allocate a buffer large enough to hold image data splitting it into one or more component arrays (planes). Depending on format, size of the line of the each picture component will have its own width (in bytes) (which may be much smaller or much larger than image width) and will also be padded to achieve the specified alignment (16 bytes typically to make vector instructions work). For example with typical YCbCr image with 4:2:0 subsampling there will be 3 planes (that is 3 non-null pointers stored in pointers
) and width of the luma plane line will be (padded) image width, width of the each chroma component lines will be (padded) half image width.
Also note that both pointers
and linesizes
in this function are out pointer parameters, not arrays.
This function will allocate a buffer large enough to hold image data splitting it into one or more component arrays (planes). Depending on format, size of the line of the each picture component will have its own width (in bytes) (which may be much smaller or much larger than image width) and will also be padded to achieve the specified alignment (16 bytes typically to make vector instructions work). For example with typical YCbCr image with 4:2:0 subsampling there will be 3 planes (that is 3 non-null pointers stored in pointers
) and width of the luma plane line will be (padded) image width, width of the each chroma component lines will be (padded) half image width.
Also note that both pointers
and linesizes
in this function are out pointer parameters, not arrays.
edited Nov 12 '18 at 18:53
answered Nov 12 '18 at 7:15
VTTVTT
24k42345
24k42345
It can’t be smaller than the width.
– szatmary
Nov 12 '18 at 14:09
@szatmary I've mentioned an example when line size is 2x smaller than image width
– VTT
Nov 12 '18 at 14:10
Fair enough. The first half just reads funny, because you must have the chroma plane at least width size.
– szatmary
Nov 12 '18 at 14:15
@szatmary Not really, chroma plane has 1/2 horizonal and vertical subsampling and each chroma line therefore is 2x smaller than image width...
– VTT
Nov 12 '18 at 14:18
I understand chroma sub sampling. On my first read of your response I felt it was less than clear. That’s ok if you disagree.
– szatmary
Nov 12 '18 at 14:27
|
show 5 more comments
It can’t be smaller than the width.
– szatmary
Nov 12 '18 at 14:09
@szatmary I've mentioned an example when line size is 2x smaller than image width
– VTT
Nov 12 '18 at 14:10
Fair enough. The first half just reads funny, because you must have the chroma plane at least width size.
– szatmary
Nov 12 '18 at 14:15
@szatmary Not really, chroma plane has 1/2 horizonal and vertical subsampling and each chroma line therefore is 2x smaller than image width...
– VTT
Nov 12 '18 at 14:18
I understand chroma sub sampling. On my first read of your response I felt it was less than clear. That’s ok if you disagree.
– szatmary
Nov 12 '18 at 14:27
It can’t be smaller than the width.
– szatmary
Nov 12 '18 at 14:09
It can’t be smaller than the width.
– szatmary
Nov 12 '18 at 14:09
@szatmary I've mentioned an example when line size is 2x smaller than image width
– VTT
Nov 12 '18 at 14:10
@szatmary I've mentioned an example when line size is 2x smaller than image width
– VTT
Nov 12 '18 at 14:10
Fair enough. The first half just reads funny, because you must have the chroma plane at least width size.
– szatmary
Nov 12 '18 at 14:15
Fair enough. The first half just reads funny, because you must have the chroma plane at least width size.
– szatmary
Nov 12 '18 at 14:15
@szatmary Not really, chroma plane has 1/2 horizonal and vertical subsampling and each chroma line therefore is 2x smaller than image width...
– VTT
Nov 12 '18 at 14:18
@szatmary Not really, chroma plane has 1/2 horizonal and vertical subsampling and each chroma line therefore is 2x smaller than image width...
– VTT
Nov 12 '18 at 14:18
I understand chroma sub sampling. On my first read of your response I felt it was less than clear. That’s ok if you disagree.
– szatmary
Nov 12 '18 at 14:27
I understand chroma sub sampling. On my first read of your response I felt it was less than clear. That’s ok if you disagree.
– szatmary
Nov 12 '18 at 14:27
|
show 5 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53257213%2fwhat-is-linesize-in-libav%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown