ad_spdif: recreate spdif muxer on reset - #18241
Conversation
|
Everyone is throwing their tokens at truehd packing it looks like. See also: |
Thanks for pointing these out. Neither of the LAV issues affect the spdifenc changes at https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/23542. Good to see kodi going to the output timing solution too. |
| // muxing the stream, and init_filter() probes codec parameters from | ||
| // this packet as well, so wait for major sync before initializing. | ||
| if (spdif_ctx->codec_id == AV_CODEC_ID_TRUEHD && | ||
| !truehd_has_major_sync(spdif_ctx->avpkt)) |
There was a problem hiding this comment.
How frequent are major sync in bitstream? What if we miss one and loop hear not outputting auto too long? Not that there is better way if we need to sync.
There was a problem hiding this comment.
It varies. Across all the movies I've sampled, most are nominally 1 major sync per 128 access units. 1/128 is also the lowest rate I've seen. A few other movies are 1/32, and one movie is 1/16.
All of the movies' truehd audio are 48kHz, which is 1200AU/s:
128/1200= ~107ms
32/1200= ~27ms
16/1200= ~14ms
Most seeks start with a major sync though. I'm only seeing this issue happen when seeking very close to known branch points in the bluray remux. When it does start without a major sync I don't perceive anything different on my decoder. Log output looks like this:
[ 19.646][v][ad] dropped 43 TrueHD packets before major sync
70656c0 to
f72080f
Compare
The spdif decoder uses avformat/spdifenc. Some spdifenc paths keep muxer state across packets, such as partial TrueHD MAT frames. After a seek, that state belongs to the old stream position and can cause the next packet to be muxed with stale timing or buffering state. On decoder reset, discard the current spdif muxer context. The next usable input packet will recreate the muxer through the existing initialization path. A fresh TrueHD spdif muxer needs a TrueHD major sync before it can begin muxing the stream. Startup or post-seek playback may begin on a TrueHD access unit that does not have major sync, so drop TrueHD packets until a major sync access unit is seen. This also gives the downstream decoder a clean restart point after seeks. Partially addresses: https://trac.ffmpeg.org/ticket/9569 Signed-off-by: Nathan Lucas <nlucasgit@gmail.com>
determine_codec_params() warns when it cannot determine a codec profile. Some passthrough formats use fixed output parameters and do not require the probed profile or sample rate making the warning misleading. Warn only when a value used to configure the selected passthrough format is missing: the profile for DTS-HD, or the sample rate for core DTS and AC-3. Signed-off-by: Nathan Lucas <nlucasgit@gmail.com>
|
A few changes:
|
| { | ||
| return pkt->size >= 8 && pkt->data[4] == 0xf8 && | ||
| pkt->data[5] == 0x72 && pkt->data[6] == 0x6f && | ||
| (pkt->data[7] & 0xfe) == 0xba; |
There was a problem hiding this comment.
This should be ... && (AV_RB32(pkt->data + 4) & 0xfffffffe) == 0xf8726fba. I'm not sure though you need MLP too? Comment suggest you do, but it's used only for truehd, no? Otherwise you can drop the mask.
2 participants
This partially addresses https://trac.ffmpeg.org/ticket/9569 by resetting the spdif context on seek so stale avformat/spdifenc timing and buffer state will not be used after the seek. This prevents an incomplete TrueHD MAT frame from remaining muxed with access units before the seek, and prevents invalid MAT padding from being calculated relative to timing before the seek.
This also silences timing discontinuity warnings from avformat/spdifenc caused by seeking.
The second commit reduces unnecessary log spam from determine_codec_params by only logging failed profile and rate probes when those values were necessary for the selected format. Normally this would only happen once, but now it would happen after every seek.
AI disclosure: OpenAI Codex assisted with the research and development of these changes. I have reviewed generated code and understand the changes that are being submitted.