Deinterlacing problem with some Top Field First videos about ksplayer HOT 18 CLOSED

@cdguy 我加了 idet。 你可以看下效果怎么样

from ksplayer.

This issue: #714 is also releated

from ksplayer.

@cnnky 我这个库是支持bwdif 这个filter的。那直接把yadif改成bwdif 是不是就可以了

from ksplayer.

@cnnky 我这个库是支持bwdif 这个filter的。那直接把yadif改成bwdif 是不是就可以了

With ffmpeg and ffplay, enabling just bwdif filter makes same horizontal vibrations in picture. I had to specify parity=0 to assume it is top field first. After that it produces the clear, 50fps smooth picture. So without specifying it's a top field first stream, bwdif couldn't produce the correct image and produces the same horizontal vibration image. That's why I think just enabling bwdif filter couldn't fix the thing.

It also makes same horizontal vibrations with yadif x2 filter, bob filter, x filter and linear filter via vlc so I think there's the same issue in here. Tested with Nvidia RTX GPU and Windows 11.

Since I don't have any other apple device I couldn't try bwdif :/. Even though I don't think just enabling the bwdif filter fixes the problem, I'm going to create a feature request for snappier to add bwdif filter and let's see if that helps.

from ksplayer.

It also makes same horizontal vibrations with yadif x2 filter, bob filter, x filter and linear filter via vlc so I think there's the same issue in here. Tested with Nvidia RTX GPU and Windows 11.

bwdif is optimised for Nvidia Graphic Cards.
besides you should consider this:

1- Apple CPUs do not have hardware decoding chip for de-interlace; because of that only software decoding can be done
2- for the stream you shared, if you use yadifx1 the stream is smooth

When I run the same ffmpeg command with the same stream; there is a common pattern like this one:

[Parsed_idet_0 @ 000001e462eebc00] Repeated Fields: Neither: 0 Top: 0 Bottom: 0
[Parsed_idet_0 @ 000001e462eebc00] Single frame detection: TFF: 0 BFF: 0 Progressive: 0 Undetermined: 0
[Parsed_idet_0 @ 000001e462eebc00] Multi frame detection: TFF: 0 BFF: 0 Progressive: 0 Undetermined: 0
Stream mapping:
Stream #0:2 -> #0:0 (h264 (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
[Parsed_metadata_1 @ 000001e45fef7040] frame:0 pts:0 pts_time:0
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.current_frame=neither
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.neither=1.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.top=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.bottom=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.current_frame=tff
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.tff=1.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.bff=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.progressive=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.undetermined=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.current_frame=tff
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.tff=1.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.bff=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.progressive=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.undetermined=0.00
Output #0, null, to 'pipe:':
Metadata:
encoder : Lavf60.17.100
Stream #0:0: Video: wrapped_avframe, yuv420p(top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 25 tbn
Metadata:
encoder : Lavc60.33.100 wrapped_avframe
[Parsed_metadata_1 @ 000001e45fef7040] frame:1 pts:3600 pts_time:0.04ed= 0x
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.current_frame=neither
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.neither=2.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.top=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.bottom=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.current_frame=tff
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.tff=2.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.bff=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.progressive=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.undetermined=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.current_frame=tff
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.tff=2.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.bff=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.progressive=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.undetermined=0.00
[Parsed_metadata_1 @ 000001e45fef7040] frame:2 pts:7200 pts_time:0.08
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.current_frame=neither
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.neither=3.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.top=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.bottom=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.current_frame=tff
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.tff=3.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.bff=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.progressive=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.undetermined=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.current_frame=tff
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.tff=3.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.bff=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.progressive=0.00
[Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.undetermined=0.00

etc, etc

based on this info; the idet command can't identify if this stream is interlaced or not (most probably because the reference frame count is 1)

However, when you do a frame by frame (single or multi) analysis, using the command ffmpeg -i http://linkstreamtotest.ts -filter:v idet,metadata=mode=print -frames:v 360 -an -f null -

here is how ffmpeg interprets (correctly the stream); and maybe this is where an improvement can be made for Ksplayer:

Single Frame Analysis:

lavfi.idet.single.current_frame=tff: The current frame is top field first (TFF).
lavfi.idet.single.tff=1.00: The percentage of frames that are TFF is 100%.
lavfi.idet.single.bff=0.00: The percentage of frames that are bottom field first (BFF) is 0%.

Multiple Frame Analysis:

lavfi.idet.multiple.current_frame=tff: Similar to the single frame analysis, this is for multiple frames.
lavfi.idet.multiple.tff=1.00: The percentage of frames, when analyzed together, that are TFF is 100%.
lavfi.idet.multiple.bff=0.00: The percentage of frames, when analyzed together, that are BFF is 0%.

I hope that helps @kingslay

from ksplayer.

用ffmpeg -i 就可以判断出这个视频是 top first

Input #0, mpegts, from '/Users/kintan/Downloads/problematic.ts':
Duration: 00:01:00.14, start: 1.400000, bitrate: 13405 kb/s
Program 1
Metadata:
service_name : Service01
service_provider: FFmpeg
Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 90k tbn
Stream #0:10x101: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 192 kb/s

用我的播放器来播放的话，应该会是流畅的

from ksplayer.

用ffmpeg -i 就可以判断出这个视频是 top first

Input #0, mpegts, from '/Users/kintan/Downloads/problematic.ts': Duration: 00:01:00.14, start: 1.400000, bitrate: 13405 kb/s Program 1 Metadata: service_name : Service01 service_provider: FFmpeg Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 90k tbn Stream #0:10x101: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 192 kb/s

用我的播放器来播放的话，应该会是流畅的

We would love to see a smooth playback but to be explain a little bit more of what is happening, I'm going to add a hdmi capture to show what's happening with deinterlacing.

https://www.mediafire.com/file/swtrkxipqbt80jg/problematic_hdmicapture.mkv/file

When we select yadif x1 for deinterlacing, the juddering gones but fps downs to 25. With yadif x2 and yadif x2 ss it's juddering a lot.

from ksplayer.

用ffmpeg -i 就可以判断出这个视频是 top first
Input #0, mpegts, from '/Users/kintan/Downloads/problematic.ts': Duration: 00:01:00.14, start: 1.400000, bitrate: 13405 kb/s Program 1 Metadata: service_name : Service01 service_provider: FFmpeg Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 90k tbn Stream #0:10x101: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 192 kb/s
用我的播放器来播放的话，应该会是流畅的

We would love to see a smooth playback but to be explain a little bit more of what is happening, I'm going to add a hdmi capture to show what's happening with deinterlacing.

https://www.mediafire.com/file/swtrkxipqbt80jg/problematic_hdmicapture.mkv/file

When we select yadif x1 for deinterlacing, the juddering gones but fps downs to 25. With yadif x2 and yadif x2 ss it's juddering a lot.

@cnnky How do you know that the app uses the latest ksplayer? You just recorded a screen record of an app…

@kingslay I will let you know when I can try the latest code.

from ksplayer.

bwdif is optimised for Nvidia Graphic Cards. besides you should consider this:

bwdif filter dont have any relations with nvidia. That's why ffmpeg has a separate bwdif cuda filter to implement in cuda. Please check the following links.

https://vsdb.top/plugins/bwdif
https://github.com/HomeOfVapourSynthEvolution/VapourSynth-Bwdif
https://www.ffmpeg.org/ffmpeg-filters.html#bwdif
https://www.ffmpeg.org/ffmpeg-filters.html#bwdif_005fcuda

1- Apple CPUs do not have hardware decoding chip for de-interlace; because of that only software decoding can be done 2- for the stream you shared, if you use yadifx1 the stream is smooth

If you check the hdmi capture It's clear that yadif x1 filter makes the picture 25fps.

When I run the same ffmpeg command with the same stream; there is a common pattern like this one:

[Parsed_idet_0 @ 000001e462eebc00] Repeated Fields: Neither: 0 Top: 0 Bottom: 0 [Parsed_idet_0 @ 000001e462eebc00] Single frame detection: TFF: 0 BFF: 0 Progressive: 0 Undetermined: 0 [Parsed_idet_0 @ 000001e462eebc00] Multi frame detection: TFF: 0 BFF: 0 Progressive: 0 Undetermined: 0 Stream mapping: Stream #0:2 -> #0:0 (h264 (native) -> wrapped_avframe (native)) Press [q] to stop, [?] for help [Parsed_metadata_1 @ 000001e45fef7040] frame:0 pts:0 pts_time:0 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.current_frame=neither [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.neither=1.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.top=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.bottom=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.current_frame=tff [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.tff=1.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.bff=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.progressive=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.undetermined=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.current_frame=tff [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.tff=1.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.bff=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.progressive=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.undetermined=0.00 Output #0, null, to 'pipe:': Metadata: encoder : Lavf60.17.100 Stream #0:0: Video: wrapped_avframe, yuv420p(top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 25 tbn Metadata: encoder : Lavc60.33.100 wrapped_avframe [Parsed_metadata_1 @ 000001e45fef7040] frame:1 pts:3600 pts_time:0.04ed= 0x [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.current_frame=neither [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.neither=2.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.top=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.bottom=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.current_frame=tff [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.tff=2.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.bff=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.progressive=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.undetermined=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.current_frame=tff [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.tff=2.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.bff=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.progressive=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.undetermined=0.00 [Parsed_metadata_1 @ 000001e45fef7040] frame:2 pts:7200 pts_time:0.08 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.current_frame=neither [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.neither=3.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.top=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.repeated.bottom=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.current_frame=tff [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.tff=3.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.bff=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.progressive=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.single.undetermined=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.current_frame=tff [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.tff=3.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.bff=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.progressive=0.00 [Parsed_metadata_1 @ 000001e45fef7040] lavfi.idet.multiple.undetermined=0.00

etc, etc

based on this info; the idet command can't identify if this stream is interlaced or not (most probably because the reference frame count is 1)

I don't agree with that reference frame count 1 part. I've had some streams in back with same juddering thing with 4 reference frames. Just to disprove reference frame thing, i've created some 4 ref-frames interlaced file that do the same juddering. Here is the file that i created.

https://www.mediafire.com/file/bizmsug8hkzpmbz/4ref-judder.ts/file

Format/Info : Advanced Video Codec
Format profile : Main@L4
Format settings : 4 Ref Frames
Format settings, CABAC : No
Format settings, Reference frames : 4 frames
Scan type : MBAFF
Scan type, store method : Interleaved fields
Scan order : Top Field First
Encoding settings : cabac=0 / ref=4

@cnnky How do you know that the app uses the latest ksplayer? You just recorded a screen record of an app…

Did kingslay say anything about 'with xxx version of ksplayer, it is fixed' or anything like that? I'm trying to explain what's happening and that's just it. After we certainly find what's happening, I think kingslay can fix it.

from ksplayer.

@kingslay

I found the command line that needs to be applied to fix (for all) this issue.

via the command line, I used ffplay to run some tests and it worked on my side:

here is the command line I applied in ffplay

ffmpeg -i "thestreamfile.ts" -vf "idet,yadif=1" -c:a copy -c:v rawvideo -f nut pipe: | ffplay -

from ksplayer.

@kingslay

I found the command line that needs to be applied to fix (for all) this issue.

via the command line, I used ffplay to run some tests and it worked on my side:

here is the command line I applied in ffplay

ffmpeg -i "thestreamfile.ts" -vf "idet,yadif=1" -c:a copy -c:v rawvideo -f nut pipe: | ffplay -

This turns out to what I said in the beginning. Specifying deinterlacing møde fixes the problem. I think what should be done to fix that issue is instead of letting yadif or bwdif filter to detect parity automatically, ksplayer should detect the parity from codec info and changes yadif or bwdif filter's parity with that information.

Seems like in ffmpeg, default parity for both bwdif and yadif filters is auto and with auto, the issue is happening. It seems like this is same for ksplayer but I'm not certain about that. That's why I created this issue and let kingslay know about this thing.

Let's wait and see what's the opinion of kingslay about this situation.

from ksplayer.

@kingslay
I found the command line that needs to be applied to fix (for all) this issue.
via the command line, I used ffplay to run some tests and it worked on my side:
here is the command line I applied in ffplay
ffmpeg -i "thestreamfile.ts" -vf "idet,yadif=1" -c:a copy -c:v rawvideo -f nut pipe: | ffplay -

This turns out to what I said in the beginning. Specifying deinterlacing møde fixes the problem. I think what should be done to fix that issue is instead of letting yadif or bwdif filter to detect parity automatically, ksplayer should detect the parity from codec info and changes yadif or bwdif filter's parity with that information.

Seems like in ffmpeg, default parity for both bwdif and yadif filters is auto and with auto, the issue is happening. It seems like this is same for ksplayer but I'm not certain about that. That's why I created this issue and let kingslay know about this thing.

Let's wait and see what's the opinion of kingslay about this situation.

the issue is not related to specify the deinterlace mode.

On the contrary it is related to the output extention.

Instead of using ffmpeg -i "thestreamfile.ts" -vf "idet,yadif=1" -c:a copy -c:v rawvideo -f nut pipe: | ffplay -

try to use ffplay -vf "yadif=1"thestreamfile.ts

you will see that the image is still shaking.

from ksplayer.

@kingslay
I found the command line that needs to be applied to fix (for all) this issue.
via the command line, I used ffplay to run some tests and it worked on my side:
here is the command line I applied in ffplay
ffmpeg -i "thestreamfile.ts" -vf "idet,yadif=1" -c:a copy -c:v rawvideo -f nut pipe: | ffplay -

This turns out to what I said in the beginning. Specifying deinterlacing møde fixes the problem. I think what should be done to fix that issue is instead of letting yadif or bwdif filter to detect parity automatically, ksplayer should detect the parity from codec info and changes yadif or bwdif filter's parity with that information.
Seems like in ffmpeg, default parity for both bwdif and yadif filters is auto and with auto, the issue is happening. It seems like this is same for ksplayer but I'm not certain about that. That's why I created this issue and let kingslay know about this thing.
Let's wait and see what's the opinion of kingslay about this situation.

the issue is not related to specify the deinterlace mode.

On the contrary it is related to the output extention.

Instead of using ffmpeg -i "thestreamfile.ts" -vf "idet,yadif=1" -c:a copy -c:v rawvideo -f nut pipe: | ffplay -

try to use ffplay -vf "yadif=1"thestreamfile.ts

you will see that the image is still shaking.

I think you should try with both send field and parity tff mode but I haven't checked yet.

from ksplayer.

@kingslay
I found the command line that needs to be applied to fix (for all) this issue.
via the command line, I used ffplay to run some tests and it worked on my side:
here is the command line I applied in ffplay
ffmpeg -i "thestreamfile.ts" -vf "idet,yadif=1" -c:a copy -c:v rawvideo -f nut pipe: | ffplay -

This turns out to what I said in the beginning. Specifying deinterlacing møde fixes the problem. I think what should be done to fix that issue is instead of letting yadif or bwdif filter to detect parity automatically, ksplayer should detect the parity from codec info and changes yadif or bwdif filter's parity with that information.
Seems like in ffmpeg, default parity for both bwdif and yadif filters is auto and with auto, the issue is happening. It seems like this is same for ksplayer but I'm not certain about that. That's why I created this issue and let kingslay know about this thing.
Let's wait and see what's the opinion of kingslay about this situation.

the issue is not related to specify the deinterlace mode.
On the contrary it is related to the output extention.
Instead of using ffmpeg -i "thestreamfile.ts" -vf "idet,yadif=1" -c:a copy -c:v rawvideo -f nut pipe: | ffplay -
try to use ffplay -vf "yadif=1"thestreamfile.ts
you will see that the image is still shaking.

I think you should try with both send field and parity tff mode but I haven't checked yet.

There is no need to use ffmpeg -i "thestreamfile.ts" -vf "idet,yadif=1:parity=tff" -c:a copy -c:v rawvideo -f nut pipe: | ffplay -
because when I use ffmpeg -i "thestreamfile.ts" -vf "idet,yadif=1" -c:a copy -c:v rawvideo -f nut pipe: | ffplay - in the media details, it is mentioned that the interlaced stream is TFF. and the stream is smooth.

Metadata:
service_name : S SPORT 2 PLATIN
service_provider: MG
Stream #0:00x100: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 192 kb/s
Stream #0:10x101: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 192 kb/s
Stream #0:2[0x102]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 90k tbn

from ksplayer.

你们可以重载process 这个方法。指定具体的filter来处理Deinterlacing。 代码如下

    open func process(assetTrack: some MediaPlayerTrack) {
        if assetTrack.mediaType == .video {
            if [FFmpegFieldOrder.bb, .bt, .tt, .tb].contains(assetTrack.fieldOrder) {
                // todo 先不要用yadif_videotoolbox，不然会crash。这个后续在看下要怎么解决
                hardwareDecode = false
                asynchronousDecompression = false
                let yadif = hardwareDecode ? "yadif_videotoolbox" : "yadif"
                var yadifMode = KSOptions.yadifMode
                if let assetTrack = assetTrack as? FFmpegAssetTrack {
                    if assetTrack.realFrameRate.num == 2 * assetTrack.avgFrameRate.num, assetTrack.realFrameRate.den == assetTrack.avgFrameRate.den {
                        if yadifMode == 1 {
                            yadifMode = 0
                        } else if yadifMode == 3 {
                            yadifMode = 2
                        }
                    }
                }
                videoFilters.append("\(yadif)=mode=\(yadifMode):parity=-1:deint=1")
                if yadifMode == 1 || yadifMode == 3 {
                    assetTrack.nominalFrameRate = assetTrack.nominalFrameRate * 2
                }
            }
        }
    }

from ksplayer.

你们可以重载process 这个方法。指定具体的filter来处理Deinterlacing。 代码如下

    open func process(assetTrack: some MediaPlayerTrack) {
        if assetTrack.mediaType == .video {
            if [FFmpegFieldOrder.bb, .bt, .tt, .tb].contains(assetTrack.fieldOrder) {
                // todo 先不要用yadif_videotoolbox，不然会crash。这个后续在看下要怎么解决
                hardwareDecode = false
                asynchronousDecompression = false
                let yadif = hardwareDecode ? "yadif_videotoolbox" : "yadif"
                var yadifMode = KSOptions.yadifMode
                if let assetTrack = assetTrack as? FFmpegAssetTrack {
                    if assetTrack.realFrameRate.num == 2 * assetTrack.avgFrameRate.num, assetTrack.realFrameRate.den == assetTrack.avgFrameRate.den {
                        if yadifMode == 1 {
                            yadifMode = 0
                        } else if yadifMode == 3 {
                            yadifMode = 2
                        }
                    }
                }
                videoFilters.append("\(yadif)=mode=\(yadifMode):parity=-1:deint=1")
                if yadifMode == 1 || yadifMode == 3 {
                    assetTrack.nominalFrameRate = assetTrack.nominalFrameRate * 2
                }
            }
        }
    }

This commit be2e1a7 does not fix the issue

that’s why I posted this code idea, which works fine with all interlaced streams ffmpeg -i "thestreamfile.ts" -vf "idet,yadif=1" -c:a copy -c:v rawvideo -f nut pipe: | ffplay -

It would be very tricky to implement very specific functions for all kind of streams if the developers are not experienced with stream types.

I can send you again the interlaced .ts streams via e-mail if you need @kingslay

from ksplayer.

@kingslay
I found the command line that needs to be applied to fix (for all) this issue.
via the command line, I used ffplay to run some tests and it worked on my side:
here is the command line I applied in ffplay
ffmpeg -i "thestreamfile.ts" -vf "idet,yadif=1" -c:a copy -c:v rawvideo -f nut pipe: | ffplay -

This turns out to what I said in the beginning. Specifying deinterlacing møde fixes the problem. I think what should be done to fix that issue is instead of letting yadif or bwdif filter to detect parity automatically, ksplayer should detect the parity from codec info and changes yadif or bwdif filter's parity with that information.
Seems like in ffmpeg, default parity for both bwdif and yadif filters is auto and with auto, the issue is happening. It seems like this is same for ksplayer but I'm not certain about that. That's why I created this issue and let kingslay know about this thing.
Let's wait and see what's the opinion of kingslay about this situation.

the issue is not related to specify the deinterlace mode.
On the contrary it is related to the output extention.
Instead of using ffmpeg -i "thestreamfile.ts" -vf "idet,yadif=1" -c:a copy -c:v rawvideo -f nut pipe: | ffplay -
try to use ffplay -vf "yadif=1"thestreamfile.ts
you will see that the image is still shaking.

I think you should try with both send field and parity tff mode but I haven't checked yet.

There is no need to use ffmpeg -i "thestreamfile.ts" -vf "idet,yadif=1:parity=tff" -c:a copy -c:v rawvideo -f nut pipe: | ffplay - because when I use ffmpeg -i "thestreamfile.ts" -vf "idet,yadif=1" -c:a copy -c:v rawvideo -f nut pipe: | ffplay - in the media details, it is mentioned that the interlaced stream is TFF. and the stream is smooth.

Metadata: service_name : S SPORT 2 PLATIN service_provider: MG Stream #0:00x100: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 192 kb/s Stream #0:10x101: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 192 kb/s Stream #0:2[0x102]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 90k tbn

It seems like without telling ffmpeg to detect interlacing type with idet command, it is still making that juddering. So both our solutions makes the correct decoding. Not sure about which one are consumes less memory and system resources. It seems like ffmpeg is analyzing every frame when we specifify idet command so it might consume a little more system resources but again i'm not sure about that. needs to be investigated.

from ksplayer.

@kingslay thank you for the fix it works perfectly!

from ksplayer.