OS: Ubuntu 12.04
As I trace the code of Simple_encode.cpp, I found something below and have question about reason of restriction of 2048. Do you know why?? Hardware design or else?? I have checked https://software.intel.com/sites/default/files/mediasdk-man.pdf but found no answer.
w /= 2;
h /= 2;
ptr = pData->UV + pInfo->CropX + (pInfo->CropY / 2) * pitch;
if (w > 2048) ==> what the restriction means ??
If you see our Release Notes, the maximum supported resolution for AVC encoder is 4096x2304. https://software.intel.com/sites/default/files/managed/de/2e/media_server_studio_sdk_release_notes_linux.pdf
w /= 2 is 2048, hence the check.
hi Sravanthi ,
many thanks for your response. More question are
Q1. the maximum supported resolution is due to hardware of software?? if software, then what's max for hardware??
H.264 decoder Supported Profiles: Baseline Main High Maximum supported resolution: 4096x2304
Q2. By your speaking, there should be more limitation like the following, right ??
if (h > 1157)
Hi Medwin - good question. It is our SW limitation (in the sense, validation wise). Our HW limitation is 4Kx4K - so you can feed up to 4Kx4K streams as well.
You can remove the tutorial limitation for width and height - so long as you keep within 4Kx4K, you shoud be alright.
hi Sravanthi ,
many thanks for your response. more question are
Q1. the mentioned limitation is also for decoder ??
Q2. what're the meaning of the following, because I can't find any info in https://software.intel.com/sites/default/files/managed/de/2e/media_server_studio_sdk_release_notes_l...
/* TargetUsages: from 1 to 7 inclusive */
MFX_TARGETUSAGE_1 =1, what's this??
MFX_TARGETUSAGE_2 =2, ...
MFX_TARGETUSAGE_3 =3, ...
MFX_TARGETUSAGE_4 =4, ...
Yes, both decoder and encoder.
Reg Q2, what are you referring to? Can you please clarify?
Reg TU modes, MSDK supports 7 target usage modes 1 through 7, with 1 being best quality and 7 being best speed (4 is balanced).So, the application developer can specify the target usage mode for his application.
If this was not what you asked, please clarify. Thanks.
Yes, they are thread-safe if they are executing in their own session.
Here is how MSDK implementation works: Each session is similar to a process, and each session basically spawns multiple threads (thread/task pool) internally and schedules the work on it. The scheduler then manages each of these threads for the session in iterms of memory and synchronization. Now, the application only has control on creating sessions, everything after that is managed internally by MSDK.
If you create multiple sessions in an application, and do not "join" them, then each session has its own resources. If you join the sessions, then MSDK creates a parent and multiple child sessions, all sharing the thread pool and scheduler managing it internally.
All this is not visible to application layer, it is internal implementation. At application level, each session will behave like a process.
Now, when you ask if it is thread safe, what thread are you talking about? If the answer above is not what you're looking for, give me some more context and may be an example.
Req (2), yes, multiple sessions within an encode is a very common scenario. Esp when you want to encode multiple streams in parallel (N:N use-case), or have one feed to other (1:N). See the readme file in "sample_multi_transcode" folder for more details on 1:N, N:N, multiple session etc.
Hi there - your questions are not related to your original form question on "question on simple_encode" anymore. Please do not add any more questions unrelated to simple_encode here. Start a new thread - it is easier for us to log and respond that way.