libavformat/mov: Expose Quicktime poster_time value as metadata TAG. #21
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Welcome to FFmpegThis is the FFmpeg Pull Request Agent for GitHub, which enables sending of patch series to the FFmpeg mailing list from GitHub Pull Requests. It is an adaption of GitGitGadget and credits belong to its creators. You are here to submit a contribution to FFmpeg? That's great! PrerequisitesFirst of all, make sure that you have read the through the Devloper Documentation Please make sure that your Pull Request has a good description, as it will be used as cover letter. Also, it is a good idea to review the commit messages one last time, as the FFmpeg project expects them in a quite specific form:
It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code. Submitting your PatchsetBefore you can submit the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a comment to your PR of the form Both the person who commented An alternative is the channel Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment If you want to see what email(s) would be sent for a After you submit, the PR Agent will respond with another comment that contains the link to the cover letter mail in the FFmpeg mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions (while the comments and suggestions will be mirrored into the PR by GitGitGadget, you will still want to reply via mail). Submitting Revised Patch VersionsTo iterate on your change, i.e. send a revised patch or patch series, you will first want to (force-)push to the same branch. You probably also want to modify your Pull Request description (or title). It is a good idea to summarize the revision by adding something like this to the cover letter (read: by editing the first comment on the PR, i.e. the PR description): To send a new iteration, just add another PR comment with the contents: Further Reference |
|
/allow |
|
User brycechesternewman is now allowed to use the FFmpeg Code Bot. WARNING: brycechesternewman has no public email address set on GitHub |
|
/submit |
|
Submitted as pull.21.ffstaging.FFmpeg.1643844144096.ffmpegagent@gmail.com To fetch this version into To fetch this version to local tag |
|
On the FFmpeg mailing list, Bryce Newman wrote (reply to this): |
|
User |
|
Invalid author email in 7d798f3: "brycechesternewman@users.noreply.github.com" |
|
There is a merge commit in this Pull Request: Please rebase the branch and force-push. |
|
/submit |
|
Invalid author email in 7d798f3: "brycechesternewman@users.noreply.github.com" |
|
There is a merge commit in this Pull Request: Please rebase the branch and force-push. |
|
/submit |
|
Invalid author email in 7d798f3: "brycechesternewman@users.noreply.github.com" |
|
There is a merge commit in this Pull Request: Please rebase the branch and force-push. |
|
/submit |
|
Invalid author email in 7d798f3: "brycechesternewman@users.noreply.github.com" |
|
There is a merge commit in this Pull Request: Please rebase the branch and force-push. |
|
Invalid author email in 7d798f3: "brycechesternewman@users.noreply.github.com" |
|
There are merge commits in this Pull Request: Please rebase the branch and force-push. |
Some audio codecs work with atomic units that decode to a fixed number of audio samples with this number being so small that it is common to put multiple of these atoms into one packet. In these cases it makes no sense to pad the last frame to the big frame_size, so allow encoders to set the number of samples that they want the last frame to be padded to instead. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do this by setting AVCodecInternal.pad_samples. This prevents reading into the frame's padding and writing into the packet's padding. This actually happened in our FATE tests (where the number of samples is 2 mod 4), which therefore needed to be updated. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
While this probably never overflows, we are better safe than sorry. The callback prototype should probably also use ptrdiff_t or size_t, but I diggress (this would affect the DSP callback prototype).
... for a difference between pointers.
The compiler cannot infer that the two float vectors do not alias, causing unnecessary extra loads and serialisation. This patch caches the two input values in local variables so that compiler can optimise individual loop iterations.
Only used there. Also make it static. Reviewed-by: James Almer <jamrial@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, using NULL as key in av_dict_get() on a non-empty AVDictionary would crash; using NULL as key in av_dict_set() would also crash for a non-empty AVDictionary unless AV_DICT_MULTIKEY was set; in case the dictionary was initially empty or AV_DICT_MULTIKEY was set, it was even possible for av_dict_set() to succeed when adding a NULL key, namely when one uses a value != NULL and the AV_DICT_DONT_STRDUP_VAL flag. Using av_dict_get() on such an AVDictionary will usually lead to crashes, though. Fix this by actually checking for key in both functions; error out if they are NULL. While just at it, also stop relying on av_strdup(NULL) to return NULL in av_dict_set(). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, libswscale/input.c used a macro to read an input pixel which involved a call to av_pix_fmt_desc_get() to find out whether the input pixel format is BE or LE despite this being known at compile-time (there are templates per pixfmt). Even worse, these calls are made in a loop, so that e.g. there are six calls to av_pix_fmt_desc_get() for every pair of UV pixel processed in rgb64ToUV_half_c_template(). This commit modifies these macros to ensure that isBE() is evaluated at compile-time. This saved 9743B of .text for me (GCC 11.2, -O3). For a simple RGB64LE->YUV420P transformation like ffmpeg -f lavfi -i haldclutsrc,format=rgba64le -pix_fmt yuv420p \ -threads 1 -t 1:00 -f null - the amount of decicycles spent in rgb64LEToUV_half_c (which is created via the template mentioned above) decreases from 19751 to 5341; for RGBA64BE the number went down from 11945 to 5393. For shared builds (where the call to av_pix_fmt_desc_get() is indirect) the old numbers are 15230 for RGBA64BE and 27502 for RGBA64LE, whereas the numbers with this patch are indistinguishable from the numbers from a static build. Also make the macros that are touched conform to the usual convention of using uppercase names while just at it. Reviewed-by: Anton Khirnov <anton@khirnov.net> Reviewed-by: Paul B Mahol <onemda@gmail.com> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, libswscale/output.c used a macro to write an output pixel which involved a call to av_pix_fmt_desc_get() to find out whether the input pixel format is BE or LE despite this being known at compile-time (there are templates per pixfmt). Even worse, these calls are made in a loop, so that e.g. there are eight calls to av_pix_fmt_desc_get() for every pixel processed in yuv2rgba64_X_c_template() for 64bit RGB formats. This commit modifies these macros to ensure that isBE() is evaluated at compile-time. This saved 41184B of .text for me (GCC 11.2, -O3). Of course, it also improved performance. E.g. ffmpeg_g -f lavfi -i testsrc2,format=yuva420p -pix_fmt rgba64le \ -threads 1 -t 1:00 -f null - (which uses yuv2rgba64le_X_c, which is an invocation of yuv2rgba64_X_c_template() mentioned above), performance improved from 95589 to 41387 decicycles for one call to yuv2packedX; for the be variant the numbers went down from 76087 to 43024 decicycles. Reviewed-by: Anton Khirnov <anton@khirnov.net> Reviewed-by: Paul B Mahol <onemda@gmail.com> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes the rv20-1239 FATE-test. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is currently 64-bit only because the stack spilling code would not assemble on RV32I (and it would corrupt s0 and s1 on RV128I, in theory). This could be added later in the unlikely that someone wants it.
ff_check_pixfmt_descriptors() was added in commit 20e99a9. At this time, the values of enum AVPixelFormat were not contiguous; instead there was a jump from 111 to 291 (or from 115 to 295 depending upon AV_PIX_FMT_ABI_GIT_MASTER). ff_check_pixfmt_descriptors() accounts for this by skipping empty descriptors. Yet this issue no longer exists: There are no holes. The check for said holes makes GCC believe that the name can be NULL; because it is used as argument corresponding to %s in a log statement, it therefore emits a warning (since d75c469). Therefore this commit simply removes these checks. Also move the checks for name before the log statement. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead use av_pix_fmt_desc_next(). It is still possible to check its return values by comparing it with the (currently) expected values and the code does so. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Namely to lavu/tests/pixelutils.c. This way, this function will not be included into actual binaries any more. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These are test tools, so they should be picky. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Regression since 9a494b8. Reviewed-by: James Almer <jamrial@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
lavu minor bump was apparently forgotten for those, so mention them in the block adding av_chroma_location*(), which was the next lavu minor bump.
This allows av_mediacodec_release_buffer to be called safely after the decoder is closed, this was already the case with delay_flush=1. Note that this causes holding onto frames to keep the decoding context alive which is generally considered to be the intended behavior. Signed-off-by: sfan5 <sfan5@live.de> Signed-off-by: Anton Khirnov <anton@khirnov.net>
The code that uses these was removed in ecee3b0 Signed-off-by: Anton Khirnov <anton@khirnov.net>
The code that defined videotoolbox_init was removed in 4b54818 Signed-off-by: Anton Khirnov <anton@khirnov.net>
Unused since removal of the -deinterlace option in d013453 Signed-off-by: Anton Khirnov <anton@khirnov.net>
Unused since the bits_per_raw_sample was made a per-output-stream option in 4258893 Signed-off-by: Anton Khirnov <anton@khirnov.net>
Forgotten in 0c0a3de.
It is only used by three of the thirty files that (potentially indirectly) include mpeg4audio.h. Twenty of these files won't have a put_bits.h inclusion any more after this patch. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This check is intended to be avoid buffer overflows, yet there are four problems with it: 1. It has an in-built off-by-one error: len == out_end - out is perfectly fine and nothing to worry about. This off-by-one error led to the pixel in the lower-right corner not being set properly for the back frame of the sample from the rl2 FATE-test. This pixel is copied to every frame which is the reason for the update to the reference file of said test. With this patch, the output of the decoder matches the output as captured from the reference decoder* (apart from the fact that said reference somehow lacks the top part of the frame (copied over from the background frame)). 2. Given that the stride of the buffer may be different from the width of the video (despite one pixel taking one byte), there is a second check lateron making the first check redundant (if one returns immediately; a simple break at the second check is not sufficient, because it only exits the inner loop). 3. The check is based around the assumption of the stride being positive (it has this in common with the other check which will be fixed in a future commit). 4. Even after fixing the off-by-one error, the check in question is still triggered by all the non-background frames in the FATE sample as well as by A1100100.RL2. In all these cases, they use len == 255 and val == 128. For videos with background frame this just means "copy from the background frame", which would be done anyway lateron.* Yet for videos without it copying it is necessary to avoid leaving uninitialized parts in the video. *: Available in https://samples.mplayerhq.hu/game-formats/voyeur-rl2/ **: Due to this, the code that copies the rest from the back frame is no longer executed for any of the samples available on the sample server. Given that these are only the files from the demo version of this game, I don't know whether this code is executed for any file in existence or not. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Don't increment back_frame if it does not correspond to a real buffer. To do this, handle copying from the back frame separately from the "use coded value" codepath; also use memcpy for the former, as the chunks here are typically worth it. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
…ernewman/FFmpeg-1 into patch-poster-time-tag
|
/submit |
|
The pull request has 3025 commits. The max allowed is 100. Please split the patch series into multiple pull requests. Also consider squashing related commits. |
1 similar comment
|
The pull request has 3025 commits. The max allowed is 100. Please split the patch series into multiple pull requests. Also consider squashing related commits. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I need the ability to derive the poster time found in the mvhd, so I can
use that value to create a thumbnail from ffmpeg. More details can be
found here
https://www.mail-archive.com/ffmpeg-user@ffmpeg.org/msg30003.html
Signed-off-by: Bryce Chester Newman bryce.newman@gettyimages.com
cc: Bryce Newman bryce.newman@gettyimages.com