According to HEVC spec:
A clean random access (CRA) picture may have associated random access skipped leading (RASL) or random access decodable leading (RADL) pictures present in the bitstream.
A broken link access (BLA) picture having nal_unit_type equal to BLA_W_LP may have associated RASL or RADL pictures present in the bitstream. A BLA picture having nal_unit_type equal to BLA_W_RADL does not have associated RASL pictures present in the bitstream, but may have associated RADL pictures in the bitstream. A BLA picture having nal_unit_type equal to BLA_N_LP does not have associated leading pictures present in the bitstream
Except the containing different NAL_unit type, there seems to be no difference between CRA and BLA with nal_unit_type equal to BLA_W_LP.
Any difference between them?
BLA pictures are very similar to CRA pictures but the main difference is, it is used for concatenating different streams (spliced video). When you concatenate two HEVC streams of different properties (like resolution, GOP, CUSize etc) CRA pictures are converted to BLA pictures. In case of CRA pictures both RASL and RADL pictures are decoded and displayed if it is not a random access where as in case of BLA pictures, RASL pictures are ignored even if it is not a random access.
Related
I am using artillery and I am exporting the results as a json file with -o result.json
The problem is that it seems that the json files structure are not consistent depending on the arrivalRate.
When arrivalRate=5, the latencies branch for the intermediate reslts contains 4 fields (see image below).
When I set arrivalRate to a higher value, for example, arrivalRate=20 the json response just includes the latency without the other 3 fields. (see image below).
I would like to get all the information as in the first image.
I just started to work with QGIS. I would like to automatically calculate, for example,
NDMI=(NIR-SWIR)/(NIR+SWIR)=(B08-B11)/(B08+B11)
for Sentinel-2 and other indices that use bands other than the RGB/NIR ones when downloading a batch of Sen2 or Landsat-8 images in QGIS using the SCP plugin.
For this, I need to define a general formula with general names for the bands to be uploaded as a TXT file in the "Band calc" that will work on all the images. I know, for example, that the special name for Sen2 B08 is "#NIR#", but "#SWIR#" does not work for B11, probably because B11 is just one of the SWIR bands available in Sen2.
I couldn't find a list or table containing the special names for Sen2 and Landsat8 bands other than the RGB/NIR ones in the SCP documentation and on the internet. I would be very grateful if someone could post this information.
Luca Congedo, the developer/owner of the SCP plugin, responded by e-mail that: "you can use the band number of the bandset for identifying bands in the band calc. For instance Sentinel-2 band 11 should be "bandset#b9" in the Band calc". In my case, the number of the bandset was 4, because I was downloding only the bands B2, B4, B8 and B11 of Sentinel-2, so I used "bandset#b4" in the formula. It worked perfectly.
I have a problem with inserting UNICODE characters in a PDF file in eclipse.
There is some solution for this that it is not very efficient for me.
The solution is like this.
document.add(new Paragraph("Unicode: \u0418", new Font(bfComic, 12)));
I want to retrieve data from a database and show them to the user and my characters are in Arabic script and sometimes in Farsi script.
What solution do you suggest?
thanks
You are experiencing different problems:
Encoding of the data:
Please download chapter 2 of my book and go to section 2.2.2 entitled "The Phrase object: a List of Chunks with leading". In this section, look for the title "Database encoding versus the default CharSet used by the JVM".
You will see that database values are retrieved like this:
String name1 = new String(rs.getBytes("given_name"), "UTF-8");
That’s because the database contains different names with special characters. You risk that these special characters are displayed as gibberish if you would retrieve the field like this:
String name2 = rs.getString("given_name")
Encoding of the font:
You create your font like this:
Font font = new Font(bfComic, 12);
You don't show how you create bfComic, but I assume that this object is a BaseFont object using IDENTITY_H as encoding.
Writing from right to left / making ligatures
Although your code will work to show a single character, it won't work to show a sentence correctly.
Suppose that name1 is the Arabic version of the name "Lawrence of Arabia" and that we want to write this name to a PDF. This is done three times in the following screen shot:
The first line is wrong, because the characters are in the wrong order. They are written from left to right whereas they should be written from right to left. This is what will happen when you do:
document.add(name1);
Even if the encoding is correct, you're rendering the text incorrectly.
The second line is also wrong. The characters are now in the correct order, but no ligatures are made: ل followed by و should be combined into a single glyph: لو
You can only achieve this by adding the content to a ColumnText or PdfPCell object, and by setting the run direction to PdfWriter.RUN_DIRECTION_RTL. For instance:
pdfCell.setRunDirection(PdfWriter.RUN_DIRECTION_RTL);
Now the text will be rendered correctly.
This is explained in chapter 11 of my book. You can find a full example here: Ligatures2
We are currently trying to merge multiple PDFs and create a PDF/A (1B) out of it.
Currently we face a problem when we want to fix the color profiles. The PDF we receive has no embedded color profiles, so during the merge functionality of PDFBox, no OutputIntents are merged. So in the last step we try to add the color profiles.
If we do not add any color profile, we get validation issues for RGB and CMYK. If we add both color profiles to the PDDocumentCatalog, then only the validation issues for the first one are gone. So if we add RGB first, we only get CMYK validation issues and vice versa.
Here is a part of the code when we add the color profiles:
public void convertToPDFA(PDDocument doc, String file){
PDMetadata metadata = new PDMetadata(doc);
PDDocumentCatalog cat = doc.getDocumentCatalog();
cat.setMetadata(metadata);
// do metadata stuff, just removed it for now
InputStream colorProfile = PDFService.class.getResourceAsStream("/pdfa/sRGB Color Space Profile.icm");
PDOutputIntent oi = new PDOutputIntent(doc, colorProfile);
oi.setInfo("sRGB IEC61966-2.1");
oi.setOutputCondition("sRGB IEC61966-2.1");
oi.setOutputConditionIdentifier("sRGB IEC61966-2.1");
oi.setRegistryName("http://www.color.org");
cat.addOutputIntent(oi);
This is the code for RGB, we also add another *.icm color profile for CMYK.
So the color profiles seem to be fine, because dependent on the one we add first, the validation issues are gone.
For me it feels like we are just missing a small thing that both color profiles will be accepted, or could it be that only one color profile can be used for the creation of a PDF/A?
Thanks in advance and kind regards
Only a single output intent is allowed, see here. An alternative is also mentioned there, which would be to use only ICC based colorspaces.
What should be possible (although beyond the scope of the question), would be to assign ICC profiles to /DeviceGray, /DeviceRGB, or /DeviceCMYK, by adding DefaultGray, DefaultRGB, or DefaultCMYK entries the ColorSpaces in the resource dictionary, as explained in section 8.6.5.6 of the PDF specification:
When a device colour space is selected, the ColorSpace subdictionary
of the current resource dictionary (see 7.8.3, "Resource
Dictionaries") is checked for the presence of an entry designating a
corresponding default colour space (DefaultGray, DefaultRGB, or
DefaultCMYK, corresponding to DeviceGray, DeviceRGB, or DeviceCMYK,
respectively). If such an entry is present, its value shall be used as
the colour space for the operation currently being performed.
Be aware that making PDF file PDF/A-1b conformant is often more trickier than just adding output intents - check your file with PDFBox preflight or with the online validator from PDF Tools, there are many possible errors. Which is why there are products from Callas Software or PDF Tools that convert PDF files to PDF/A.
The PDF Spec defines standard structure types, used to define a structure tree for the document. As far as I can see, there is no element related to pages. Here are the standard structure types for grouping elements:
Document
Part
Art
Sect
Div
...and so on...
Why is there no Page item in this list?
If you want your structure to use pages, what should be used? Part? Sect? Div?
PDF tags exist so that the content type / meaning of elements can be identified. They should be considering a kind of "meta" information for the PDF, simply providing context for the content in a file (so that content can be easily extracted, converted, processed, accessible, etc.). Think of it as a table of contents to a book. Just because the book has x pages doesn't mean that the content structure would be altered if the book's page height was cut in half and now had 2x pages in it.
A Page Object in the PDF Document Structure already groups elements (by nature of each element being on a given page), so doing so in this structure would be a little redundant.
Also, consider this case:
Document
Table of Contents (Page 1)
Section 1 (starts on page 2, ends mid page 3)
Sub Section (page 2)
Sub Section (half of page 3)
Section 2 (starts mid page 3)
etc...
In this example, Section 1 and Section 2 couldn't both be direct parents of page 3 (not to mention that Section 1 spans two different pages). Additionally, trying to solve this problem really isn't necessary because the elements which is being grouped here is already each a child of its respective Document Structure's Page node in the actual file format.
Appendix G of the PDF Specification gives examples that demonstrate use of the Page object.
The PDF has a tree structure (which is what allows it to load any page so fast). The content does not have any structure unless you choose to use the marked content feature of the format which then allows metadata to be include in the data.