Chiebot-Mirror/FFmpeg - FFmpeg - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Anton Khirnov	129c7bf53f	fftools/ffmpeg: always use the same path for setting InputStream.[next_]dts Currently those are set in different ways depending on whether the stream is decoded or not, using some values from the decoder if it is. This is wrong, because there may be arbitrary amount of delay between input packets and output frames (depending e.g. on the thread count when frame threading is used). Always use the path that was previously used only for streamcopy. This should not cause any issues, because these values are now used only for streamcopy and discontinuity handling. This change will allow to decouple discontinuity processing from decoding and move it to ffmpeg_demux. It also makes the code simpler. Changes output in fate-cover-art-aiff-id3v2-remux and fate-cover-art-mp3-id3v2-remux, where attached pictures are now written in the correct order. This happens because InputStream.dts is no longer reset to AV_NOPTS_VALUE after decoding, so streamcopy actually sees valid dts values.	2 years ago
Anton Khirnov	9543161800	framehash: convert to new channel layout API Signed-off-by: James Almer <jamrial@gmail.com>	3 years ago
James Almer	a42d249c91	avformat/framecrcenc: print basic side data information again This partially reverts `c6ae560a18`. Signed-off-by: James Almer <jamrial@gmail.com>	4 years ago
Anton Khirnov	c6ae560a18	lavf/framecrcenc: do not hash side data There are no guarantees that all side data types have the same representation on all platforms. Tests that change output due to this: id3v2-priv-remux, cover-art-mp3-id3v2-remux, gapless-mp3: SKIP_SAMPLES, which is tested by fate-gapless-mp3-side-data matroska-vp8-alpha-remux: MATROSKA_BLOCKADDITIONAL, which is tested by remux itself (side data is written into output) matroska-mastering-display-metadata: MASTERING_DISPLAY_METADATA and CONTENT_LIGHT_LEVEL, which are tested by ffprobe invocation in the same test matroska-spherical-mono-remux: STEREO3D and SPHERICAL, which are tested by ffprobe invocation in the same test segment-mp4-to-ts: MPEGTS_STREAM_ID, which is tested by ts remuxing tests webm-webvtt-remux: WEBVTT_IDENTIFIER/SETTINGS, which is tested by the ffprobe invocation in the same test mxf-d10-user-comments: CPB_PROPERTIES, which is tested by mxf-probe-d10 mov-cover-image: SKIP_SAMPLES, which is tested for mov by mov-aac-2048-priming copy-trac3074: AUDIO_SERVICE_TYPE, which is tested by fate-hls-fmp4_ac3	4 years ago
Andreas Rheinhardt	8068f2fcf3	avformat/id3v2: Don't reverse the order of id3v2 APICs When parsing ID3v2 tags, special (non-text) metadata is not applied directly and unconditionally; instead it is stored in a linked list in which elements are prepended. When traversing the list to add APICs (or private tags) at the end, the order is reversed. The same also happens for chapters and therefore the chapter parsing code already reverses the chapters. This commit changes this: By keeping pointers to both head and tail of the linked list one can preserve the order of the entries and remove the reordering code for chapters. Only the pointer to head will be exported: No current caller uses a nonempty list, so exporting both head and tail is unnecessary. This removes the functionality to combine the lists of special metadata read from different ID3v2 tags, but that doesn't make really much sense anyway (and would be trivial to implement if desired) and allows to remove the now unnecessary initializations performed by the callers. The FATE-reference for the id3v2-priv test had to be updated because the order of the tags read into the dict is reversed; for id3v2-priv-remux only the md5 and not the ffprobe output of the remuxed file changes because the order of the private tags has up until now been reversed twice. The references for the aiff/mp3 cover-art tests needed to be updated, because the order of the attached pics is reversed upon reading. It is still not correct, because the muxers write the pics in the order in which they arrive at the muxer instead of the order given by pkt->stream_index. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	4 years ago
Andreas Rheinhardt	2f4ef9cbdf	fate/cover-art: Add test for writing id3v2 tags and apic with AIFF/MP3 Notice that the order of the APIC tracks is currently wrong. This is a superposition of two bugs: (i) Both muxers write the attached pictures in the order they arrive in the muxer and not in the stream_index order, leading to attached pictures that are copied being written earlier because their timestamp is AV_NOPTS_VALUE, whereas the timestamp of the encoded pictures is 0. (ii) A bug in the id3v2 parsing code reverses the order of the parsed pictures. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	4 years ago