Wrong framerate

[hatsatsaa]

Hi!

Info shows, that framerate is 50. It should be 25.
Example: https://drive.google.com/file/d/1o0rNibaMrcn7NBGxYlyjsRY2emhU3win/view

Thanks!

[eumagga0x2a]

This is not that simple. The video is a mixture of interlaced and not interlaced frames at macroblock level (MBAFF). While the user-visible frame increment remains 40 ms (25 fps), there are some frames/fields 20 ms (50 fps) apart shortly after 15 seconds in the video (the spot also can't be decoded properly). It would be more helpful to have a look at the original transport stream, not at the result of remuxing it into MKV (with .ts as wrong file extension).

[hatsatsaa]

How about this one: https://drive.google.com/open?id=1ap1mhKEyr7i2Yf6jlgqogUL5P49mocic

[eumagga0x2a]

Thank you for the sample, it is basically the same: most of the frames are really frames at 25 fps, but there are a few spots with fields (at 50 fps) like this one:

Code Select Expand

Frame 01510 Flags d000 (B/T) DTS 00:01:00,520 PTS 00:01:00,600
Frame 01511 Flags d000 (B/T) DTS xx:xx:xx,xxx PTS 00:01:00,560
Frame 01512 Flags d000 (B/T) DTS 00:01:00,600 PTS 00:01:00,640
Frame 01513 Flags 9000 (P/T) DTS 00:01:00,640 PTS 00:01:00,840 <-- look at the DTS
Frame 01514 Flags a000 (P/B) DTS 00:01:00,660 PTS 00:01:00,860 <-- look at the DTS
Frame 01515 Flags d000 (B/T) DTS 00:01:00,680 PTS 00:01:00,760 <-- look at the DTS
Frame 01516 Flags e000 (B/B) DTS 00:01:00,700 PTS 00:01:00,780
Frame 01517 Flags d000 (B/T) DTS xx:xx:xx,xxx PTS 00:01:00,720
Frame 01518 Flags d000 (B/T) DTS 00:01:00,760 PTS 00:01:00,800
Frame 01519 Flags 9000 (P/T) DTS 00:01:00,800 PTS 00:01:01,000
Frame 01520 Flags d000 (B/T) DTS 00:01:00,840 PTS 00:01:00,920
Frame 01521 Flags d000 (B/T) DTS xx:xx:xx,xxx PTS 00:01:00,880
Frame 01522 Flags d000 (B/T) DTS 00:01:00,920 PTS 00:01:00,960
Frame 01523 Flags 9000 (P/T) DTS 00:01:00,960 PTS 00:01:01,160
Frame 01524 Flags a000 (P/B) DTS 00:01:00,980 PTS 00:01:01,180
Frame 01525 Flags d000 (B/T) DTS 00:01:01,000 PTS 00:01:01,080
Frame 01526 Flags d000 (B/T) DTS xx:xx:xx,xxx PTS 00:01:01,040
Frame 01527 Flags d000 (B/T) DTS 00:01:01,080 PTS 00:01:01,120
Frame 01528 Flags 9000 (P/T) DTS 00:01:01,120 PTS 00:01:01,320
Frame 01529 Flags d000 (B/T) DTS 00:01:01,160 PTS 00:01:01,240 <-- look at the DTS
Frame 01530 Flags e000 (B/B) DTS 00:01:01,180 PTS 00:01:01,260 <-- look at the DTS
Frame 01531 Flags d000 (B/T) DTS xx:xx:xx,xxx PTS 00:01:01,200
Frame 01532 Flags d000 (B/T) DTS 00:01:01,240 PTS 00:01:01,280
Frame 01533 Flags 9000 (P/T) DTS 00:01:01,280 PTS 00:01:01,480
Frame 01534 Flags d000 (B/T) DTS 00:01:01,320 PTS 00:01:01,400
Frame 01535 Flags d000 (B/T) DTS xx:xx:xx,xxx PTS 00:01:01,360
Frame 01536 Flags d000 (B/T) DTS 00:01:01,400 PTS 00:01:01,440
Frame 01537 Flags 9010 (I/T) DTS 00:01:01,440 PTS 00:01:01,640
Frame 01538 Flags d000 (B/T) DTS 00:01:01,480 PTS 00:01:01,560
Frame 01539 Flags d000 (B/T) DTS xx:xx:xx,xxx PTS 00:01:01,520


(the above is the output to the Avidemux log by the command

Code Select Expand

ed=Editor()
for frame in range(1510,1540): ed.printTiming(frame)

in the scripting shell from the "Tools" menu)

and we get 50 fps officially advertised by the SPS (function extractSPSInfo) too.

[hatsatsaa]

Hi!

If I don't resample FPS, audio and video don't sync.

Thanks!

[eumagga0x2a]

Please clarify which editing steps led to A-V desync. I didn't notice any sync issues with the sample (apart from one audio track missing timestamps), neither in Avidemux nor in video players. There are AFAIR three audio tracks, are they all equally affected?

[hatsatsaa]

Hi!

I mean after I convert it to mkv, there's sync problem with my Sony bluray-player. There's no sync problem with my pal's Samsung player.

Thanks!

[hatsatsaa]

Hi!

Here's mkv: https://drive.google.com/open?id=1L3JXk9jn45oi6gyiWQo7eXXA77S0iOy_

With my sony player, it stops every 4 seconds and continue instantly.

Thanks!

[eumagga0x2a]

Actually, the current Avidemux can't save the stream in copy mode to MKV without causing decoding errors when playing the result. When looking closer, it turns out to be that some missing frames (e.g. frames 673, 674, 675, 676) are completely empty (in the original stream, these frames are not empty but small and contain a lot of filler data at the tail).

The re-encoded video is detected as 25 fps by Avidemux (yes, the default frame duration is 20 ms = 50 fps, but it detects that the real fps is 25) plays absolutely fine in software players on PC, also in those which decode the video in hardware. If the Sony player gets confused by the default frame duration, it is a bug in the player, because the default duration matters only if timestamps in the video are missing, which is not the case here. You can force 25 fps by editing the *.idx2 file and reloading the original TS if it is necessary to work around the player bug.

Thank you very much for the sample of the original stream.

[eumagga0x2a]

Actually, the current Avidemux can't save the stream in copy mode to MKV without causing decoding errors when playing the result. When looking closer, it turns out to be that some missing frames (e.g. frames 673, 674, 675, 676) are completely empty (in the original stream, these frames are not empty but small and contain a lot of filler data at the tail).

This should be fixed by [coreUtils/infoExtractorH264] Truncate frames instead of dropping when the number of NALUs exceeds max, this can happen with filler data present.

Does the sample originate from DVB as directly recorded by a receiver? Or was it retransmitted over network locally? I wonder whether all the filler data, split into NAL units matching the size of MPEG-TS packets, was injected by the broadcaster or by some kind of a local streaming server.

[hatsatsaa]

Hi!

It was locally retransmitted over network.

Thanks!

[eumagga0x2a]

Do you have the original TS by chance? I am really curious whether the broadcaster or the streaming device is responsible for this crazy thing with hundreds of tiny filler NALUs per Access Unit.

[hatsatsaa]

Hi!

I have the original ts. It's size 3,5G. I could later send another ts, which is smaller and shorter.
However, after resample FPS, everything works.


Thanks!

[eumagga0x2a]

I'd need just the head (~100 MiB would be enough) of the original stream (not retransmitted over network) to check whether it contains the same filler data.