HLS offers the EXT-X-PROGRAM-DATE-TIME tag that
associates the first sample of a
Media Segment with an absolute date and/or time
What is the equivalent of PROGRAM-DATE-TIME for MPEG-DASH?
I looked into mpeg-dash events but they associate arbitrary metadata to a period of time. What I need is to associated time to a segment.
I looked into mpeg-dash descriptors but as far as I could understand from the spec they associate metadata to a period/adaption-set. Things like audio configuration, frame packing, drm protection. I don't think descriptors can associate metadata with a specific segment (by segment I mean an element described by the <S> tag in the MPD).
I know that PROGRAM-DATE-TIME falls into the more general category of associating arbitrary metadata with a segment so I looked into the segment description in the MPEG-DASH spec (5.3.9.6.3 in ISO/IEC 23009-1) and I noticed that in addition to "t", "d" and "r" any other other attribute can also be specified. But the spec doesn't say a word on the meaning or format of these additional attributes. I guess they are left to the application. But still I am wondering if there is any standardized name for specifying an absolute date and time?
presentationTimeOffset is the DASH equivalent to PDT
https://dashif-documents.azurewebsites.net/DASH-IF-IOP/master/DASH-IF-IOP.html#timing-sampletimeline
Related
In an endless HLS stream, I'm not sure how to implement the EXT-X-DISCONTINUITY-SEQUENCE tag.
The RFC states :
If the server removes an EXT-X-DISCONTINUITY tag from the Media
Playlist, it MUST increment the value of the EXT-X-DISCONTINUITY-
SEQUENCE tag so that the Discontinuity Sequence Numbers of the
segments still in the Media Playlist remain unchanged. The value of
the EXT-X-DISCONTINUITY-SEQUENCE tag MUST NOT decrease or wrap.
Clients can malfunction if each Media Segment does not have a
consistent Discontinuity Sequence Number.
The media playlist I create always have the same number of segments, and the older one gets deleted when a newer one is added. Sometimes, there might be a discontinuity between two segments, so I add an EXT-X-DISCONTINUITY to the segment. However, after some time, when there are no more discontinuities in the playlist, I remove this tag and should increment the EXT-X-DISCONTINUITY-SEQUENCE.
Since the stream is endless, it will have to wrap at some point. How do people usually implement this ?
The value of EXT-X-DISCONTINUITY-SEQUENCE is defined as a decimal-integer which is defined as a number in the range 0 - 2^64 - 1 (see https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis-09#section-4.2)
Even if you were incrementing EXT-X-DISCONTINUITY-SEQUENCE many many times a second (which the question implies you are not) it seems highly unlikely you would need to handle wrapping of this value.
Given the possible range and relatively slow incrementing in the general case, I seriously doubt anyone worries about wrapping this value, but I'd be interested to be proved wrong.
I have to configure the input and output bus formats in the drm bridge driver. I am trying to understand the difference between the two.
According to Kernel Org Docs - Kernel Mode Setting (KMS)
format
format used on this bus (one of the MEDIA_BUS_FMT_* format)
This field should not be directly modified by drivers
(drm_atomic_bridge_chain_select_bus_fmts() takes care of the bus
format negotiation).
and
color_formats
HDMI Color formats, selects between RGB and YCrCb modes. Used
DRM_COLOR_FORMAT_ defines, which are not the same ones as used to
describe the pixel format in framebuffers, and also don’t match the
formats in bus_formats which are shared with v4l.
it seems to be different data structures at a frist glance. Further information might be found under Media Bus Formats.
I wonder if there is an obvious and elegant way to add additional data to a jpeg while keeping it readable for standard image viewers. More precisely I would like to embed a picture of the backside of a (scanned) photo into it. Old photos often have personal messages written on the back, may it be the date or some notes. Sure you could use EXIF and add some text, but an actuall image of the back is more preferable.
Sure I could also save 2 files xyz.jpg and xyz_back.jpg, or arrange both images side by side, always visible in one picture, but that's not what I'm looking for.
It is possible and has been done, like on Samsung Note 2 and 3 you can add handwritten notes to the photos you've taken as a image. Or some smartphones allow to embed voice recordings to the image files while preserving the readability of those files on other devices.
There are two ways you can do this.
1) Use and Application Marker (APP0–APPF)—the preferred method
2) Use a Comment Marker (COM)
If you use an APPn marker:
1) Do not make it the first APPn in the file. Every known JPEG file format expects some kind of format specific APPn marker right after the SOI marker. Make sure that your marker is not there.
2) Place a unique application identifier (null terminated string) at the start of the data (something done by convention).
All kinds of applications store additional data this way.
One issue is that the length field is only 16-bits (Big Endian format). If you have a lot of data, you will have to split it across multiple markers.
If you use a COM marker, make sure it comes after the first APPn marker in the file. However, I would discourage using a COM marker for something like this as it might choke applications that try to display the contents.
An interesting question. There are file formats that support multiple images per file (multipage TIFF comes to mind) but JPEG doesn't support this natively.
One feature of the JPEG file format is the concept of APP segments. These are regions of the JPEG file that can contain arbitrary information (as a sequence of bytes). Exif is actually stored in one of these segments, and is identified by a preamble.
Take a look at this page: http://www.sno.phy.queensu.ca/~phil/exiftool/#JPEG
You'll see many segments there that start with APP such as APP0 (which can store JFIF data), APP1 (which can contain Exif) and so forth.
There's nothing stopping you storing data in one of these segments. Conformant JPEG readers will ignore this unrecognised data, but you could write software to store/retrieve data from within there. It's even possible to embed another JPEG file within such a segment! There's no precedent I know for doing this however.
Another option would be to include the second image as the thumbnail of the first. Normally thumbnails are very small, but you could store a second image as the thumbnail of the first. Some software might replace or remove this though.
In general I think using two files and a naming convention would be the simplest and least confusing, but you do have options.
Does anyone know how to do trick modes (rewind/forward at different speeds) with MPEG-DASH ?
DASH-IF Interoperability Points V3.0 states that it is possible.
the general idea is laid out in the document but the details are not specified.
A DASH segmenter should add tracks with a frame rate lower than normal to a specially marked AdaptationSet. Roughly you could say (even though in theory you should look at the exact profile/level thresholds) half frame rate is double playoutrate. A quarter frame rate is quadruple playoutrate.
All this is only an offer to the DASH client to facilitate ffwd. The client can use it but doesn't have to. If the DASH client doesn't understand the AdaptationSet at all it will disregard it due the EssentialProperty that marking it as track play AdaptationSet.
I can't see that fast rewind can be supported in any spec conforming way. You'd need to implement it according to your needs but with no expectation of interoperability.
You can try an indication on ISO/IEC 23009-1:2014(E) =>
Annex A
The client may pause or stop a Media Presentation. In this case client simply stops requesting Media Segments or parts thereof. To resume, the client sends requests to Media Segments, starting with the next Subsegment after the last requested Subsegment.
If a specific Representation or SubRepresentation element includes the #maxPlayoutRate attribute, then the corresponding Representation or Sub-Representation may be used for the fast-forward trick mode. The client may play the Representation or Sub-Representation with any speed up to the regular speed times the specified #maxPlayoutRate attribute with the same decoder profile and level requirements as the normal playout rate. If a specific Representation or SubRepresentation element includes the #codingDependency attribute with value set to 'false', then the corresponding Representation or Sub-Representation may be used for both fast-forward and fast-rewind trick modes.
Sub-Representations in combination with Index Segments and Subsegment Index boxes may be used for efficient trick mode implementation. Given a Sub-Representation with the desired #maxPlayoutRate, ranges corresponding to SubRepresentation#level all level values from SubRepresentation#dependencyLevel may be extracted via byte ranges constructed from the information in Subsegment Index Box. These ranges can be used to construct more compact HTTP GET request.
At present, when I go to Plus and look at photos taken through Glass, I see metadata like this:
Location Add a location
Date taken 6/7/13, 1:09 PM
Dimensions 2528 x 1856
File name 20130607_130926_201.jpg
File size 1.49M
Camera Glass 1
Focal Length 2.95mm
Exposure -
F Number f/2.48
ISO -
Camera make Google
Flash Not used
Exposure Bias -
Views -
I'd love to use the Glass' built-in GPS (or even my Android's GPS, if necessary) to add a location to the image.
My hack is to subscribe to the user's Locations and immediately query for latest location upon receipt of a photo. However, there are obvious accuracy limitations to this approach.
...is there a setting I'm missing somewhere that lets me enable this? (Asking for more metadata, like ISO and exposure, will probably come in another question or a more direct request to Google)
Thanks!
AKA
Location information is not included in the EXIF data on photos taken by Glass.
But there is one simplification that we can make to your current solution. The timelineItem also contains location information. You can use this instead of making an additional request to the locations collection.
This should contain location at the time the original timeline item is created (when the photo is taken), but there's a known issue which causes it to be stale. The data is no less accurate than what you're already fetching, though, so at least it will save you a request to the API.