-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create encoder #2
Conversation
void get_image_from_raw_frame(vpx_image_t *img, UnifexPayload *raw_frame) { | ||
convert_between_image_and_raw_frame(img, raw_frame, RAW_FRAME_TO_IMAGE); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[NIT] do we need that wrapper function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i judged this function not pretty enough and deserving of a wrapper
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the other hand, it adds one layer of abstraction - but you can leave it if you think it looks nicer, the name is rather self-explanatory
const vpx_codec_cx_pkt_t *packet = NULL; | ||
|
||
unsigned int frames_cnt = 0, allocated_frames = 1; | ||
UnifexPayload **encoded_frames = unifex_alloc(allocated_frames * sizeof(*encoded_frames)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this syntax even allowed? :O What are encoded_frames
in sizeof(*encoded_frames)
? Does it mean the same as sizeof(UnifexPayload*)
? :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, it's just a size of the pointer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i took it from h264_ffmpeg_plugin
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you set it to UnifexPayload *
instead? I have some trust issues with this syntax :D
|
||
native = Native.create!(state.codec, width, height, pixel_format, state.encoding_deadline) | ||
{flushed_buffers, encoder_ref} = | ||
maybe_recreate_encoder(ctx.pads.input.stream_format, stream_format, state) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure that it is the old stream format that is available in the ctx
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this field not the last received stream format on given pad? I checked on the call to handle_stream_format and it was set to nil
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://hexdocs.pm/membrane_core/Membrane.Element.PadData.html#t:t/0 docs would suggest so too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, but I wasn't sure whether the most recent stream format received on this pad is the one that has just been received and is handled by this callback, or the previous one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if it's nil on first call i think it's safe to assume that it's the previous one
Co-authored-by: Łukasz Kita <[email protected]>
|
||
native = Native.create!(state.codec, width, height, pixel_format, state.encoding_deadline) | ||
{flushed_buffers, encoder_ref} = | ||
maybe_recreate_encoder(ctx.pads.input.stream_format, stream_format, state) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, but I wasn't sure whether the most recent stream format received on this pad is the one that has just been received and is handled by this callback, or the previous one
encoder will take as long as it needs to produce the best frame possible. Note that | ||
this is a soft limit, there is no guarantee that the encoding process will never exceed it. | ||
If set to `:auto` the deadline will be calculated based on the framerate provided by | ||
incoming stream format. If it's `nil` a fixed deadline of 10ms will be set. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same as in case of the vp8 encoder
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🥇
No description provided.