profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/jeeb/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

jeeb/kirikiri2 58

Git-svn clone of kirikiri2's svn repository

jeeb/aquaplus-sources 49

A git clone of the Aquaplus GPL source code release disc

jeeb/avisynth 20

Avisynth's CVS repository in git, revisited (this time keeping the master clean).

jeeb/ffdshow-tryouts 6

ffdshow-tryouts git svn clone

jeeb/anope-tl-jp 5

Japanese translation of the Anope IRC services.

jeeb/avisynth2 3

Avisynth 2.x CVS repo in git.

jeeb/dshow-build 3

Directshow playback components build repo

jeeb/android_device_huawei_u8800-cm9 2

IDEOS X5 hardware configuration for CM9

jeeb/arib_std_b25 2

Sample implementaion of Japanese Broadcast Conditional Access System.

jeeb/ffmpeg 2

the CCCP LAV Filters' ffmpeg repository

pull request commentmpv-player/mpv

stream/dvbin: remove "full-featured" API includes

@CounterPillow thanks for the quick PR and responses to reviews.

CounterPillow

comment created time in 2 days

push eventmpv-player/mpv

Nicolas F

commit sha 5bf92b628d0d27675a06f94da827299131ff698b

stream/dvbin: remove "full-featured" API includes In Linux kernel commit 819fbd3d8ef36c09576c2a0ffea503f5c46e9177 these two header files were moved to staging (though they've since been moved out again by Linus.) We do not actually use this, and it's in a state of maybe-removal from the kernel as of Linux 5.14. Get rid of it; mpv still builds fine without it, so it wasn't needed anyways. Fixes #9233.

view details

push time in 2 days

PR merged mpv-player/mpv

stream/dvbin: remove "full-featured" API includes

We do not actually use this, and it's in a state of maybe-removal from the kernel as of Linux 5.14. Get rid of it; mpv still builds fine without it, so it wasn't needed anyways.

Fixes #9233.

+0 -2

3 comments

1 changed file

CounterPillow

pr closed time in 2 days

issue closedmpv-player/mpv

mpv fails to build with --enable-dvbin on linux 5.14+

mpv version and platform versions

affects mpv 0.33.1, and the related source files have not been touched since then.

Reproduction steps

Building mpv with --enable-dvbin fails with linux 5.14 kernel headers, because the /usr/include/linux/dvb/video.h was (re)moved, which is included in mpv's stream/dvbin.h.

Looking at recent linux kernel headers, this file seems to have been removed without replacement. Not sure what the expected action for application developers is.

Expected behavior

mpv should continue to compile (though I'm not sure how to resolve this issue, since the kernel headers are just gone, without obvious replacement).

Actual behavior

mpv fails to compile with --enable-dvbin.

Log file

Build logs don't contain anything helpful other than the obvious "file /usr/include/linux/dvb/video.h not found".

closed time in 2 days

decathorpe
PullRequestReviewEvent

pull request commentmpv-player/mpv

stream_dvb: remove "full-featured" API include

Oh boy, IMGFMT_MPEGPES is one trippy thing to have existed :D . At least the audio output utilized either raw big endian 16bit int, or specifically MPEG-2 Audio or AC-3.

CounterPillow

comment created time in 2 days

pull request commentmpv-player/mpv

stream_dvb: remove "full-featured" API include

If we look at the history:

  1. In 16145ff43fd92947cb8fe301ebce46e7be52a9fb libvo/vo_mpegpes.c got the axe. Configure check stayed the same.
  2. In 7e2edad8efea55e8df1faa695d1389ef4e326d7c waftools/fragments/dvb.c the DVB configure contained this stuff (it was contained in the configure script as well, so this is just migration of what was to waf)
  3. In 67888a41e72dac35c4736c8a4f946c7f06148427 the configure check and the DVB input were synchronized with regards to required headers.
  4. In 915722e035cf93fa142ab5b0a56215502bf18ea9 original configure check from which these includes were copied goes away.

And this is how this seemingly unrelated DVB file gained these includes, even though anything related never utilized them :) .

CounterPillow

comment created time in 2 days

pull request commentmpv-player/mpv

stream_dvb: remove "full-featured" API include

Congratulations, this stuff goes right back to 2002 (2e399f394d686f2f8dc763af7b2535fb1e184012) , when this file was still called libvo/vo_mpegpes.c o_O

CounterPillow

comment created time in 2 days

issue commentmpv-player/mpv

How I can get mpv app bundle for M1 chip (arm native) ?

There have been thoughts about adding automated builds, and it would require various amounts of effort be put into the Github Actions stuff. But definitely now possible as you can see with https://github.com/BtbN/FFmpeg-Builds/ as an example.

The two main bits (simplified) would be:

  1. Building base sysroots with all the deps (this would probably be a separate repo with tarball and/or Docker container release artifacts).
  2. Utilizing them in conjunction with the CI actions.

This is so that no single person would have to run stuff manually.

People are free to contribute towards such things and poke us on IRC or so. One thing with macOS is due to how the Github actions images already contain a lot of stuff installed through Homebrew. You'd have to clean a lot of that up, to only have python3, meson, ninja, autotools... so that the rest could be built outside.

effolkronium

comment created time in 3 days

PR closed mpv-player/mpv

demux_mkv: fix correct start pts for eac3

eac3 audio gets pts of following demuxer audio packet resulting in not starting with correct pts. This is probably due to audio parser buffering data and not outputting audio packet before it is fed next packet. To fix this let the audio parser set pts instead of mkv internal mkv demuxer.

In my tests with a video with eac3 audio I get pts of the first two audio frames as: 0.032000 0.064000 after the patch I get: 0.000000 0.032000

I have also tested by disabling the internal mkv demuxer so the ffmpeg mkv demuxer is used instead. That also results in first audio packet having 0.000000 as pts. ffprobe also says first packet should have pts 0 I have not tested if other audio formats that also need an audio parser have the same problem.

+2 -0

29 comments

1 changed file

DanOscarsson

pr closed time in 4 days

pull request commentmpv-player/mpv

demux_mkv: fix correct start pts for eac3

Thanks once again for the contribution, applied as 162efb44b575dd42a792d27583f5940bafbb57b3 in master.

DanOscarsson

comment created time in 4 days

push eventmpv-player/mpv

Dan Oscarsson

commit sha fa767b626859cb2e4fbbc29f0b308d3638c10149

demux_mkv: enable AVCodec parser timestamp usage for parsed audio Without this, cases where the parser cannot return data right away will end up utilizing the following fed packet's timestamps. This will in turn cause an unnecessary offset in the audio stream timestamps. An example of such buffered parser in libavcodec is the EAC3 one.

view details

push time in 4 days

pull request commentmpv-player/mpv

demux_mkv: fix correct start pts for eac3

This gave me some grey hair thinking of the best solution with regards to TrueHD, and thankfully decided to have another discussion with nev.

01:05 <@JEEB> nevcairiel: but in other words, you're actually enjoying the same bug in
              LAV?
01:05 <@nevcairiel> seems so
01:05 <@JEEB> and you presumably have bit streaming users, which is what I most thought
              of
01:05 <@JEEB> alright
01:05 <@JEEB> that clears my head
01:05 <@JEEB> no if truehd => hacks, even though technically the correct behavior leads
              to incorrect timestamps with the first thing
01:10 <@nevcairiel> you could possibly fix it in the parser
01:11 <@nevcairiel> a dumb fix would be to just set the flag to get a new timestamp once
                    it finds a major sync
01:11 <@nevcairiel> a better fix would be trying to figure out why the data is going
                    missing, it doesnt seem intentional
01:15 <@nevcairiel> .. although the data is useless, so it can be forgiven, but usually
                    we dont want to discard data unasked in a parser

So it seems like the first timestamp issue is not fatal, so I will be pulling this in now :) , while on the FFmpeg side the parser issue is getting looked into.

DanOscarsson

comment created time in 4 days

delete branch jeeb/mpv

delete branch : add_forgotten_enable_variants_for_enabled_features

delete time in 4 days

push eventjeeb/ffmpeg

Jan Ekström

commit sha 8e161c0be9e64b374c22fc525831ed9772319316

avformat/aviobuf: add a full string reading mode to read_line_to_bprint Additionally: * rename it to read_string_to_bprint * split most of ff_read_line_to_bprint_overwrite into an internal function which can then be utilized to implement other functionality without duplicating code. Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>

view details

Jan Ekström

commit sha ac20b125eed643285af542b28bb8ebfe653f8cb9

avformat/{aviobuf,avio_internal}: add ff_read_string_to_bprint_overwrite For now, same as ff_read_line_to_bprint_overwrite, but reads until the end of a null-terminated string. Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>

view details

Jan Ekström

commit sha 8aa284b09291394511044be309a3d4e789536113

avformat/{aviobuf,avio_internal}: add max_len argument to ff_read_string_to_bprint_overwrite This is especially useful when reading things such as null-terminated strings from MOV/MP4-likes, where the size of the box is known, but not the exact size of the string. Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>

view details

Jan Ekström

commit sha 1914875cad4aa786c845c43744100dd3c0561df2

avformat/{isom,mov,movenc}: add support for CMAF DASH roles This information is coded in a standard MP4 KindBox and utilizes the scheme and values as per the DASH role scheme defined in MPEG-DASH. Other schemes are technically allowed, but where multiple schemes define the same concepts, the DASH scheme should be utilized. Such flagging is additionally utilized by the DASH-IF CMAF ingest specification, enabling an encoder to inform the following component of the roles of the incoming media streams. A test is added for this functionality in a similar manner to the matroska test. Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>

view details

Jan Ekström

commit sha 38b09ec5c4d69764336c476f187a165841c3d66c

avformat/{isom,movenc}: add kind box compatibility mode for Unified Origin Unfortunately the current production versions of this software do not 100% adhere to the CMAF specification, and have decided to utilize the HTML5 media track identifier for audio descriptions. This way the default mode of operation is according to the CMAF specification, but it is also possible to output streams with which this piece of software is capable of interoperating with. Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>

view details

push time in 4 days

create barnchjeeb/ffmpeg

branch : kind_box_v3

created branch time in 4 days

pull request commentmpv-player/mpv

demux_mkv: fix correct start pts for eac3

Alright, in the end I ended up making an issue on the FFmpeg trac for the TrueHD parser issue that I noticed during review/testing of this change set: https://trac.ffmpeg.org/ticket/9428 . Will have to see if me or someone else can improve this later, since while this is a minor inconvenience, it's still an inconvenience - esp. since the "technically incorrect" previous code happened to get the correct value back :D (since the last fed packet's timestamp was utilized and since the TrueHD parser did not have buffering delay, you got the correct pts for the first random access point). Also for historical reference the first bit of audio related parsing was added in 3e562583e573366fee713ecae614a49624551cc3 (funny how it references one of the exact files I'm still testing with, years later).

Thankfully the following buffers would get the correct PTS allocated to them in either case.

DanOscarsson

comment created time in 5 days

push eventjeeb/mpv

Dudemanguy

commit sha 573f696077026f6d008574234399518a0e810ee7

wayland: remove unused includes Presentation time only lives in in wayland_common.

view details

Dudemanguy

commit sha 76bddaccd63ee60245881dc188d3e15356f093f1

wayland: always be sure to initially try to render A subtle regression from c26d833. On sway if mpv was set to be a floating window in the config, set_buffer_scale would actually get applied twice according to the wayland log. That meant a 1920x1080 window would appear as a 960x540 window if the scale of the wl_output was set to 2. This only affected egl on sway (didn't occur on weston and was too lazy to try anything else; probably they were fine). Since wl->render is initially false, that meant that the very first run through the render loop returns false. This probably caused something weird to happen with the set_buffer_scale calls (the egl window gets created and everything but mpv doesn't write to it just yet) which makes the set_buffer_scale call happen an extra time. Since it was always intended for mpv to initally render, this is worth fixing. Just chnage wl->render to wl->hidden (again) and flip the bools around. That way, the initial false value results in render == true and mpv tries to draw on the first pass. This fixes the weird scaling behavior because reasons.

view details

Dudemanguy

commit sha a02901cae77c86fb9de997a418296d1fc0e3eada

wayland: fix wl_surface_set_buffer_scale usage The wl_surface lives for the entire lifetime of the vo. It's only neccesary to set the scale initially and when the output scaling changes (the surface moves to a different output with a different scale or the output itself changes it scale). All of the calls that were being made in the egl/vulkan resize functions are not needed. vo_wlshm wasn't correctly rescaling itself before this commit since it had no logic to handle scale changes. This should all be shared, common code in the surface/output listeners.

view details

rcombs

commit sha 0c1544e66cb980bd8a1dedb13ac07904380da608

sub: fix subs/lyrics on music files with sub-past-video-end=no Regressed in 11423acf3

view details

Dudemanguy

commit sha f2afae55e95b4b1eec1aeb828ba6ff1f0695d993

wayland: refactor surface scaling Another day, another wayland refactor. Way back when, dcc3c2e added support for the hidpi-window-scale option (something you probably should never set to no but whatever) to wayland. Well technically, it never had any runtime toggling support (don't remember if detecting when vo_opts changed was possible or not then; maybe not). Anyways in the process of fixing that, I went ahead and refactored how this is all handled. The key difference is that when hidpi-window-scale is disabled, wl->scaling is directly set to 1 instead of forcibly setting wl->current_output->scale to 1. Note that scaling operations don't always require a geometry reset/resize so set_surface_scaling needs to be separate from set_geometry. The logic here is kind of complicated but it (should) be correct.

view details

Avi Halachmi (:avih)

commit sha d2dd4cacb804f8f95f648c6dc4b0b9481ffa9410

osc: expose osc-visibility via shared-script-properties osc-visibility can already be changed at runtime via script-message or other means, but until now there was no way to tell what the current state is. Now shared-script-properties/osc-visibility reflects this state. It's output-only by the osc - changing it does not affect the osc. Useful if a script wants to change osc-visibility temporarily, and later restore to its original state. There's no way to coordinate if more than one script wants to change it, but that would be a hard problem to solve anyway, even if the osc itself tried to coordinate such requests from different sources.

view details

Guido Cella

commit sha b3fccf080369730e1b4d6a3435c90124a74566f7

player: add append-play flag to loadlist Closes #5664.

view details

TheAMM

commit sha 27db175ab6ba4f821d92fff3c2d6186b91fe567a

recorder: clear packet queue after they've been muxed In commit f7678575a5d7f598abf267cb303e0a74db276f27, wm4 chooses to mux all remaining packets when mp_recorder_mark_discontinuity() is called and adds a call to mux_packets(). However, it is called only after flush_packets(), which clears the packets before they can be muxed out. This has no ill effects per se - recordings end on keyframes, as before - but judging from his commit message, the intention explicitly was to output the inter frames, since long GOPs can mean several seconds of missing content from the output. So, clear the stream packet queues only after the final mux. Also, flushing can mean both discarding and committing. What a country!

view details

TheAMM

commit sha dd9ed47c996a4e37b2ac529390ba133b62fb204a

demux, dump-cache: fix demux cache range sorting dump_cache() calls qsort() to order an array of pointers, while the comparator forgets it's receiving pointers to pointers. Since cache-dumping over multiple cache ranges is fairly rare, this seems to have gone unnoticed.

view details

TheAMM

commit sha b0386fc5434e393d5e9dee97663ca59a22f2ef96

av_common: trim FLAC extradata when copying codec params For muxing, FFmpeg expects the FLAC extradata to be just the bare STREAMINFO, and passing the full FLAC extradata (fLaC header and block size, with any additional channel layout metadata) will result in malformed output, as ffmpeg will simply prefix another fLaC header in front. This can be considered to be a bug. FFmpeg's own demuxers only store the STREAMINFO, hence the naivety, while our common source of FLAC streams, the matroska demuxer, holds onto the full extradata. It has been deemed preferable to adjust the extradata upon muxing, instead of in the demuxer (ffmpeg's FLAC decoder knows to read the full fLaC extradata). This fixes muxing FLAC streams, meaning recorder.c or dump-cache.

view details

TheAMM

commit sha f9527497c68c86b247ade965dafe362f0f43be09

recorder: ignore packet queue in mux_packets() I've looked and studied the flow in the recorder, and to my understanding, the packet queue is moot after the initial sync, maybe even then - but that's beyond me right now. With the previous choice to mux trailing packets whatever the case, this doesn't result in any new ill effects (and some missing packets at the end is no big deal). Notably, since we don't have to hold onto the packets after we get muxing, we'll never run into any issues with veeery long GOPs filling up our queue (resulting in dropped packets and much user chagrin).

view details

TheAMM

commit sha 4d3df1c842532e3a48578ab6daef39076289c8ef

recorder: add support for attachments (fonts) Though, only when the output format is matroska, to avoid muxing errors. This is quite useful when the input has ASS subtitles, as they tend to rely on embedded fonts.

view details

Guido Cella

commit sha f049acfd43990828ad72e684a4fce7b74c8aa62d

manpage: fix typo

view details

Guido Cella

commit sha 383acd41a8d8f0620b0bf20bb2be23d629d67285

manpage: DEL key: clarify it refers to the osc

view details

Ripose

commit sha 34cfe9d89b19b3080bf62168803a8cb239c03c4c

command: add secondary-sub-start and secondary-sub-end properties Adds secondary-sub-start and secondary-sub-end properties by setting the current_track index in the m_property's priv variable which later gets accessed in get_times. Also adds a test of the secondary subtitle time properties in tests/subtimes.js bound to 'T'.

view details

Ripose

commit sha c4f982637ff7d85130e53a85ab1b268cf3fe02ed

command: adds support for secondary subs to sub-seek and sub-step Modifies the sub-seek and sub-step commands with a second <flags> argument to specify whether to seek/step on the primary or secondary subtitles. The flag is used to index into the current_track array in cmd_sub_step_seek.

view details

Ripose

commit sha f223edb6160eb9e54c81179bc7698e18da3cb2e7

DOCS/options: adds documentation for secondary-sub-visibility The --secondary-sub-visibility options was previously undocumented in the pull request that added it. This commit adds documentation for it and clarifies its behavior.

view details

Martin Tournoij

commit sha 854404a6395a5d9d2129f34c1f9bb6ec58c7425b

terminal-unix: fix ^Z identification When using "stty susp ''" to disable sending the TSTP signal with ^Z, mpv didn't recognize ^Z correctly in the terminal: [input] No key binding found for key 'Ctrl+2'. Because ASCII 26 (^Z) and above were incorrectly considered ^<NUMBER>. This commit moves the cutoff between letters/numbers from 25 to 26 so that ^Z is now detected correctly as ^<LETTER>. Additionally, it rephrases the ^<NUMBER> formula for clarity.

view details

Avi Halachmi (:avih)

commit sha d828652f248f152c5794a7d3a41e5732a5327e36

lua: fix timers comment (no-op) process_timers() doesn't return an absolute time. It returned delta>0 or nil before f73814b1 , and since f73814b1 it can also return 0.

view details

Shreesh Adiga

commit sha be81470f5464abcb31095f6c86380b354a16ba2d

audio: check ao driver init failure to avoid use after free reinit_audio_filters_and_output function will free mpctx->ao_chain when there is a failure during audio initialization. So modify it to return -1 in case of init failure. The return value is checked to avoid use after free. Reported by Address Sanitizer when manually specifying --ao which triggers "Failed to initialize audio driver" error.

view details

push time in 5 days

pull request commentmpv-player/mpv

waftools/features: add forgotten enable variants for enabled features

Quoting myself from IRC just to have this available here on the PR as well:

22:25 < JEEB> btw, I think I figured out the reasoning why this might have been done
22:25 < JEEB> "we want to break people who kept having the enable- switch for options
              that are already enabled"
22:26 < JEEB> since that forces the users to clean out their configure lines
22:26 < JEEB> while having warnings etc doesn't
jeeb

comment created time in 5 days

pull request commentmpv-player/mpv

waftools/features: add forgotten enable variants for enabled features

Did my due diligence testing:

1. Default
 
Checking for Disable all known FFmpeg ABI violations                      : yes
 
grep "_ABI" build/config.h
#define HAVE_FFMPEG_STRICT_ABI 1
 
2.
--enable-ffmpeg-strict-abi  |grep ABI
Checking for Disable all known FFmpeg ABI violations                      : yes
 
grep "_ABI" build/config.h
#define HAVE_FFMPEG_STRICT_ABI 1
 
3.
--disable-ffmpeg-strict-abi  |grep ABI
Checking for Disable all known FFmpeg ABI violations                      : disabled
 
grep "_ABI" build/config.h
#define HAVE_FFMPEG_STRICT_ABI 0
 
4.
--enable-ffmpeg-strict-abi --disable-ffmpeg-strict-abi |grep ABI
Checking for Disable all known FFmpeg ABI violations                      : disabled
 
grep "_ABI" build/config.h
#define HAVE_FFMPEG_STRICT_ABI 0
 
5.
--disable-ffmpeg-strict-abi --enable-ffmpeg-strict-abi |grep ABI
Checking for Disable all known FFmpeg ABI violations                      : yes
 
grep "_ABI" build/config.h
#define HAVE_FFMPEG_STRICT_ABI 1
jeeb

comment created time in 5 days

push eventjeeb/mpv

Jan Ekström

commit sha fe8771addfa7e6305fc2546abc649512d815164d

waftools/features: add forgotten enable variants for enabled features This brings enabled features on the same level as disabled and auto-detected features by having both alternatives available. Looking at the commit message of 652895abdce4bc1ff2f00c7f21c0d0d722680806 this seems to have been the intent from the start, but this specific definition was missing from the option creation in Features.

view details

push time in 5 days

push eventjeeb/mpv

Jan Ekström

commit sha 30dda1126edaf2d4fac175e2586c7cefa4d01e80

waftools/features: add forgotten enable variants for enabled features This brings enabled features on the same level as disabled and auto-detected features by having both alternatives available. Looking at the commit message of 652895abdce4bc1ff2f00c7f21c0d0d722680806 this seems to have been the intent from the start, but this specific definition was missing from the option creation in Features.

view details

push time in 5 days

pull request commentmpv-player/mpv

waftools/features: add forgotten enable variants for enabled features

As 652895abdce4bc1ff2f00c7f21c0d0d722680806 technically explicitly mentions only autodetected and disabled features, it is possible that enabled-by-default features lack this stuff intentionally, but it still is a discrepancy, esp. if a setting mid-life changes its default.

jeeb

comment created time in 5 days

pull request commentmpv-player/mpv

waftools/features: add forgotten enable variants for enabled features

Takes care of the issue addressed by #9220 by improving the feature definitions.

jeeb

comment created time in 5 days

PR opened mpv-player/mpv

waftools/features: add forgotten enable variants for enabled features core:waf

This brings enabled features on the same level as disabled and auto-detected features by having both alternatives available.

Looking at the commit message of 652895abdce4bc1ff2f00c7f21c0d0d722680806 this seems to have been the intent from the start, but this specific definition was missing from the option creation in Features.

+1 -0

0 comment

1 changed file

pr created time in 5 days

create barnchjeeb/mpv

branch : add_forgotten_enable_variants_for_enabled_features

created branch time in 5 days

pull request commentmpv-player/mpv

demux_mkv: fix correct start pts for eac3

Thanks for the response.

The reason for the segment time base (1e9 / segment_timescale) usage is that it is time base of the document itself, so the packets' timestamps in a given matroska document are stored at that precision. Just thought it was more relevant than hard-coding 1eXYZ. If we were to hard-code a value it would probably make sense to just spell it out instead of utilizing the AV_ define (which could in theory change on FFmpeg's side).

The sample rate check is not really required, but I thought it was another valid alternative in case the track time base for some reason gets really low. In reality whether it is the sample rate or the document time base it probably doesn't matter as long as we actually utilize the timestamps from the parser :)

In any case, once again thanks for taking the time, and I will most likely start pulling a version of this PR in towards the week-end.

DanOscarsson

comment created time in 9 days

pull request commentmpv-player/mpv

drm_common: handle unknown connector types, sync mappings

I think the only question from me would be whether we should utilize the same string for unknown connector types for connectors that are not known by DRM, and not known by mpv.

With this patch set the former would get "Unknown", and the latter would get "UNKNOWN". Not sure if we require a distinction - and if not, I think we should just utilize the same string.

notro

comment created time in 9 days

pull request commentmpv-player/mpv

demux_mkv: fix correct start pts for eac3

@DanOscarsson Would you be OK with something like https://github.com/jeeb/mpv/commits/pr8967 for the change set and commit message?

That said, looking at both of the old CCCP TrueHD samples (1, 2), utilizing the parser timestamps does lead to a fun result:

Before:

[   0.046][d][mkv] mkv_parse_and_add_packet: parser->pts: 0, new->pts: 0.092000
[   0.046][d][mkv] mkv_parse_and_add_packet: parser->pts: 0, new->pts: 0.093000
[   0.046][d][mkv] mkv_parse_and_add_packet: parser->pts: 0, new->pts: 0.094000
[   0.046][d][mkv] mkv_parse_and_add_packet: parser->pts: 0, new->pts: 0.095000
[   0.046][d][mkv] mkv_parse_and_add_packet: parser->pts: 0, new->pts: 0.096000
[   0.046][d][mkv] mkv_parse_and_add_packet: parser->pts: 0, new->pts: 0.097000
[   0.046][d][mkv] mkv_parse_and_add_packet: parser->pts: 0, new->pts: 0.097000
[   0.046][d][mkv] mkv_parse_and_add_packet: parser->pts: 0, new->pts: 0.098000
[   0.046][d][mkv] mkv_parse_and_add_packet: parser->pts: 0, new->pts: 0.099000
[   0.046][d][mkv] mkv_parse_and_add_packet: parser->pts: 0, new->pts: 0.100000

After:

[   0.061][d][mkv] demux_mkv_open_audio: picking between sample rate (48000) and segment timebase (1000)
[   0.067][d][mkv] mkv_parse_and_add_packet: parser->pts: 0, new->pts: 0.000000
[   0.067][d][mkv] mkv_parse_and_add_packet: parser->pts: 4464, new->pts: 0.093000
[   0.067][d][mkv] mkv_parse_and_add_packet: parser->pts: 4512, new->pts: 0.094000
[   0.067][d][mkv] mkv_parse_and_add_packet: parser->pts: 4560, new->pts: 0.095000
[   0.067][d][mkv] mkv_parse_and_add_packet: parser->pts: 4608, new->pts: 0.096000
[   0.067][d][mkv] mkv_parse_and_add_packet: parser->pts: 4656, new->pts: 0.097000
[   0.067][d][mkv] mkv_parse_and_add_packet: parser->pts: 4656, new->pts: 0.097000
[   0.067][d][mkv] mkv_parse_and_add_packet: parser->pts: 4704, new->pts: 0.098000
[   0.067][d][mkv] mkv_parse_and_add_packet: parser->pts: 4752, new->pts: 0.099000
[   0.067][d][mkv] mkv_parse_and_add_packet: parser->pts: 4800, new->pts: 0.100000

Overall duration of the track ends up the same, but there is now a nice difference between the first and second received piece of data from the parser. Will have to see the next time I'm looking into this if this is indeed correct behavior or if we need to do something additional here :) . MLP|TrueHD are set for full parsing in FFmpeg's matroska demuxer, but I've not yet compared the full parsing logic in libavformat/utils.c to what demux_mkv does for parsing.

DanOscarsson

comment created time in 10 days

push eventjeeb/mpv

Dan Oscarsson

commit sha 7f7653c68098a7c2f9a6b948878add5e3d9c7551

demux_mkv: enable AVCodec parser timestamp usage for parsed audio Without this, cases where the parser cannot return data right away will end up utilizing the following fed packet's timestamps, which may cause an unnecessary offset in the audio stream timestamps.

view details

push time in 10 days