On Sun, 2 Aug 2020, Dave Rice wrote:
On Aug 1, 2020, at 5:26 PM, Marton Balint <c...@passwd.hu> wrote:
On Sat, 1 Aug 2020, Michael Niedermayer wrote:
On Sat, Aug 01, 2020 at 07:28:53PM +0200, Marton Balint wrote:
On Sat, 1 Aug 2020, Michael Niedermayer wrote:
Fixes: Ticket8762
Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc>
---
libavformat/dv.c | 49 +++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 42 insertions(+), 7 deletions(-)
If "dv remux loses sync", then the timestamps should be fixed, not
additional packets should be generated based on previously read packet data
(which is a fragile approach to begin with, e.g. what if the first frame is
the corrupt one?).
Ticket8762 is about stream copy, so if no packets are returned for audio
but are for video and just timestamps are updated this would at least on
its own probably not work that well.
If the timestamps are good, a good player should be able to play it
correctly, even if audio stream is sparse.
None of the demuxers generate packets because the timestamps are not
continous, I just don't think it would be consistent if DV suddenly
started to do this. E.g. what if the user wants to drop video with no
audio?
In practice, when dv frames with video and no audio are interleaved
within a dv stream that otherwise has both, it is because the playback
videotape player of the dv tape is in pause mode or the tape is damaged.
These frames most common are filled with only video dif blocks that note
concealment (so the image is a copy of a prior image) and the audio
source pack metadata is missing, but the paylock of the audio dif blocks
are filled with error code so they would decode as silence.
But if the audio source pack metadata is missing, then how can you
determine the audio settings? Or the number of samples the errornous
frame contains (e.g. 1600 v.s 1602)?
At least can you assume that audio settings are the same throughout a
recording? Or DV can have mid-stream audio setting changes?
I did a test of 114 dv tape transfers
61 no difference in demuxing between pass and drop (using this patch)
31 the difference is only in the final frames so the impact of the
demuxer option would be hard for the user to see, no loss of sync, just video
with no audio at the end
22 the difference occurs mid-stream, with the drop option the demuxer
outputs video and audio at different rate when hitting frames with no audio
source pack, so the output of the demuxer loses sync
about the case of a damaged first frame. Do you have a testcase ?
No, but it can happen, can't it? If the stream starts with no audio for 1
second you will have 1 second A-V desync, as far as I see, that is why I
believe fixing the timestamps is the proper fix.
Yes this happens (though it is more rare and didn’t occur in the test
noted above). In that case, ffmpeg shows no audio at all and I’d have to
read the stream at later frames using -skip_initial_bytes.
I guess this should be fixed as well, although if there is no way to
determine the audio settings, this might prove to be difficult. Maybe the
probing should keep reading the file until an audio source pack is found
and cache that instead of relying on the last pack? At least that would
give you more consistent results, irrespective of the order of
reads/seeks, etc. But this can only work if audio settings are the same
throughout a file, can we assume that?
Also maybe setting the CORRUPT packet flag should be done in this case?
Regards,
Marton
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org <mailto:ffmpeg-devel@ffmpeg.org>
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
<https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org <mailto:ffmpeg-devel-requ...@ffmpeg.org> with subject
"unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".