Arbitrary GOP structure in HM reference software - hevc

I am using trying to setup an arbitrary GOP structure (a GOP structure other than hierarchical B or IPPP...) in HM-16.3. I fiddled around with the configuration file setting up the GOP pattern. However, I do not know how I can force the encoder to choose a particular reference frame from a list of reference frames in the reference picture set. Is this even possible in the reference encoder?

It is possible to change the GOP structure of the HM without manipulating the source code and only with the config parameters.
You are right, it's way too complicated.
I can explain it here but surely I can not explain it as good as the way it is explained in the reference manual.
And it seems that you've just done it with trial and error.
Take a look at this manual at page 3.
Also this is an example of how it works:

Related

How can the --add-section switch of OBJCOPY be used?

There are really two questions that revolve around the use of --add-section. The simple one is in the title. Based on my reading, I haven't been able to figure out how one could execute --add-section.
To use add-section, I have to pass a section name. If I use an existing section name the program responds with "can't add section '.data': File in wrong format." Perhaps I just need to pass another parameter. If I use a new section name, which I would prefer to do, I'm warned that "allocated section '.blob' not in segment."
Now, I have gotten my feature to work as I need it to aside from the "not in segment" warning. I'd like to figure out if there is a legitimate way to put this blob into the executable. I would link it in, but that isn't so easy because the data I'm adding is generated from the contents of the executable itself.
The second question is really what I care about. Is there a way to do the following given that the blob cannot be computed until after the link is complete.
Link ELF file
Generate blob from ELF file and other data
Add blob to ELF file so that it is loaded at run-time to the correct location in memory
objcopy --add-section .blob=blob.o \
--set-section-flags .blob=alloc,contents,load,readonly \
--change-section-address .blob=ADDRESS \
program.elf program.blobbed.elf
I'd be happy to add a section and/or segment to the ELF file as part of the link and insert this blob there. I'm not sure how to do that.
It has occurred to me that I could accomplish this feat with a second link, but objcopy would be cleaner.
Link ELF file
Generate blob from ELF file and other data
Re-link ELF file including new blob.o
UPDATE: This last strategy may be workable as long as the relink doesn't change something in the portion of the program that was produced by the first link. It doesn't on first attempts, but it may be possible to work around it. Hence, the desire to use --add-section to add in this blob instead of going through a second link.
You may add that section, fill it with, say, NULs, and then compute your blob. Then patch that blob into this section. Later, when you check the integrity of the ELF, do as if that section was full of NULs and compute the blob again. Finally, compare both computed blob and blob stored in section.
Not specifically answering your question but one approach I used to use for this sort of thing was to link in a placeholder block and then just patch the correct value in afterwards.
I know this isn't what you want to do, but it is a pretty simple and reliable way to do it. And has the major advantage of being tool chain/platform agnostic.

What are the specifications for a Wavefront .obj file?

I want to write a parser for Blender's .obj file. The file format seems self explanatory, but also it seems to be missing some data. For example, a simple cube (the default Blender cube) has 8 lines of vertexes, but I was expecting to see 36 lines (12 triangles to form a cube).
I think the confusion, at lease for me, stems from the way cubes are created in direct3d. Direct3d requires 36 vertexes to form a cube. So I am thinking that I need to infer the other 28 vertexes. This type of guessing could cause issues later on when trying to parse vertexes for more complex shapes. So, I thought if I could find the official specs on the file format it might provide me with some insight into how to interpret the data.
It seems that someone else had asked the same question before: How to get proper number of vertices in OBJ file from DCC tools such as Blender for use in OpenGL ES?
but it didn't have any useful information for me.
OBJ Spec
MTL Spec (you'll probably want this too at some point)
FYI OBJ is in no way related to Blender, it's just a common file format for simple models.

What open source tools could help me understand a large legacy application written in C?

I need a tool that I can use to get a better understanding of a large C
project. I'd like to be able to see the relationship between the various C
modules and what calls what, most used functions, what headers are used, etc.
I've searched here and Google but all the source code analysis tools seem to give
you the number of lines of code and other metrics that I'm not interested in. I just
want to get a high level view of how things are structured and interconnected before jumping into the code.
Does anything like this exist?
I've looked at these but they do not seem to do what I want: Source Code Tools
Since posting this I've tried Doxygen and it seems to give me some of what I need. Any others?
Try GNU cflow, that will analyze the call tree of the functions - you will nicely see the call hierarchy of the functions. Or browse the code with Eclipse.
Source Navigator may be helpful for some things (I used it to see call trees). See screenshots.
cxref builds annotated source code cross reference that's easy to view and navigate (I used to create HTML reference of some of my code). See cxref's output on its own source code here. Can be used to document the code.
It is not OSS, but the tool CppDepend can certainly help when it comes to understand a large legacy application written in C or C++.

How to get metadata from video-movie file using Objective-c?

Any help? Now can get NSSize, duration and its all.
You can do this almost entirely using Spotlight's metadata.
For example, I do the following in one of my apps
MDItemRef fileMetadata=MDItemCreate(NULL,(CFStringRef)eachPath);
NSDictionary *metadataDictionary = (NSDictionary*)MDItemCopyAttributes (fileMetadata,
(CFArrayRef)[NSArray arrayWithObjects:(id)kMDItemPixelHeight,(id)kMDItemPixelWidth,nil]);
This code essentially asks for the pixel width and height for a movie file (to determine if it's the dimension of an HD movie or not is the reason).
The Spotlight Metadata Attributes Reference lists all the available keys for various file types by category. You can probably get the required data this way without doing anything significant, provided that the media type you're examining has a Spotlight plug-in.
This functionality may not be built in (I'm honestly not sure), but I do know of two third-party libraries which can tell you the information you need.
VLCKit, the framework being used by the newest beta versions of VLC for Mac.
libmediainfo, a multi-purpose library that can read practically any bit of information you need out of practically any media file.
I can go into more depth with how to use either of these, but I'd rather only do so if you end up needing me to. Let me know!

How to generate navigation tree in doxygen output?

If you've used javadoc and then come to doxygen, you may know what I mean when I say I miss the hierarchical (frame-based) view that made jumping from class to class and method to method easy. (For those who haven't seen it, imagine a tree-navigator in an IDE or over a filesystem).
How can I get Doxygen to include a navigation tree, if it's even possible?
A similar question was asked in October, but that was just about stylesheet alternatives and only one turned up. I think I'm looking for something more major.
Note that all you need to do to get the tree on the left in Quinn's example is setting GENERATE_TREEVIEW to YES in the config file.
At a basic level, Doxygen output is what it is, and I don't think there's "a better way to view" static HTML content. I think what you want is for Doxygen to produce HTML output that is more similar to Javadoc, which has both pros and cons. (The biggest drawback is that it's unlikely to happen, due to the effort involved and the broad user base.)
I manage a project that is documented using Doxygen, and I'm not sure to what degree my config uses the Doxygen defaults, but I get a sections in the left frame for a flat class list and a class hierarchy. Also, since I have diagrams enabled, the Graphical Class Hierarchy is a fairly quick way to jump to where I want. I haven't delved into Doxygen modules, so I don't have any experience with whether that might segment things similar to how Javadoc does with packages.