30 replies to this topic

[jbollacke]

Hi,

 

i am using OpenPLI 4.0 (last updated today) and i found the following bug:

 

While playing some MKV files, autoresolution detects the wrong frame rate of 23.976 fps (Original frame rate in mediainfo) instead of fps Hz (Frame rate in mediainfo). This results in a stutter once per second.

 

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.1
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 5 frames
Codec ID                                 : V_MPEG4/ISO/AVC
Duration                                 : 57mn 16s
Bit rate                                 : 3 581 Kbps
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 25.000 fps
Original frame rate                      : 23.976 fps
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.155
Stream size                              : 1.43 GiB (89%)
Writing library                          : x264 core 140 r2377 1ca7bb9
Encoding settings                        : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=18 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Default                                  : Yes
Forced                                   : No
Matrix coefficients                      : BT.709

This file plays fine when AutoResolution is disabled and TV stays at 50 Hz (multiple of 25).

 

Why does AutoResolution (using iServiceInformation of enigma) retrieve the wrong (original) frame rate? I think this should be fixed.

[littlesat]

Which box?

[jbollacke]

Xtrend ET9200

[littlesat]

Here I cannot verify/confirm your issue... here autoresolution switches correctly...????

[Erik Slagter]

I guess there is discrepancy between the frame rate specified by the codec (explicit, or implicit using pts) and the container (mkv). The question is, how has this happened?

[jbollacke]

Here I cannot verify/confirm your issue... here autoresolution switches correctly...????

AutoResolution switches correctly to the wrong frame rate.

 

I guess there is discrepancy between the frame rate specified by the codec (explicit, or implicit using pts) and the container (mkv). The question is, how has this happened?

I do not know how media info determines the "original frame rate" and the "frame rate" properties. Neither I know why this happened but I have a few files (german tv shows / WEB-DL) where this is the case.

 

But according to the naming used in mediainfo I would assume that "frame rate" is the intended frame rate and "original frame rate" is there for informational purpose.

Edited by jbollacke, 15 May 2014 - 12:02.

[jbollacke]

Here is the mkvinfo output of the video track:

 

| + Ein Track
|  + Tracknummer: 1 (Track-ID für mkvmerge & mkvextract: 2)
|  + Track UID: 535886232
|  + Tracktyp: video
|  + Flag für Paketbündelung: 0
|  + MinCache: 1
|  + Codec-ID: V_MPEG4/ISO/AVC
|  + private Codecdaten, Länge 43 (h.264-Profil: High @L4.1)
|  + Standarddauer: 40.000ms (25.000 Bilder/Felder pro Sekunde im Falle eines Videotracks)
|  + Sprache: und
|  + Video-Track
|   + Pixelbreite: 1280
|   + Pixelhöhe: 720
|   + Anzeigebreite: 1280
|   + Anzeigehöhe: 720

I am sorry that it is in german but as you can see (at Standarddauer) the container suggests a default duration of 40ms for every block resulting in 25 fps. Looks like iServiceInformation ignores this and just provides the framerate of the h264 inside the mkv container which is 23.976 fps.

 

john@server /some/path $ mediainfo video.h264
General
Complete name                            : video.h264
Format                                   : AVC
Format/Info                              : Advanced Video Codec
File size                                : 1.46 GiB

Video
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.1
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 5 frames
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 23.976 fps
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Writing library                          : x264 core 140 r2377 1ca7bb9
Encoding settings                        : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=18 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Matrix coefficients                      : BT.709

Edited by jbollacke, 16 May 2014 - 07:05.

[Erik Slagter]

It may (or may not) help to extract the video track (only the video track, no demuxing!) and insert it again. But this action may also completely destroy a/v sync. Point is you simply have a corrupt file, both values should be in line.

[jbollacke]

It may (or may not) help to extract the video track (only the video track, no demuxing!) and insert it again. But this action may also completely destroy a/v sync. Point is you simply have a corrupt file, both values should be in line.

I do not think that this will help. The VUI header of the h264 bitstream - the one that suggests 23.976 fps - is not touched and therefore mediainfo will still report "original frame rate" as 23.976 fps , iServiceInformation/enigma2 will report that framerate and autoresolution will switch to 24 hz mode again.

 

Neither I think that this is a corrupt file. The container just overrides the timing information of the raw video stream.

[Erik Slagter]

It is corrupt because the two sources do no match and they should. It's not in the meaning "got corrupted", but in the meaning "not a valid file".

 

When you re-mux, mkvmerge will inspect the h264 stream and see the stream is 23.97 fps. The information in de container is lost then.

[malakudi]

According to this, mkv container does not specifically report framerate. The "original frame rate" in mediainfo is extracted from the H.264 frames. So I agree that this is an inconsistent problematic file.

[jbollacke]

I can't see the requirement for them to match in the mkv specification. Where did you read that?

 

BTW: every other application (totem, vlc, ffmpeg, avprobe) report back 25 fps.

[Erik Slagter]

I can't see the requirement for them to match in the mkv specification. Where did you read that?

Don't think it would be sort of common sense that both frame rates in the container and in the h264 stream match? The expression "original frame rate" that mediainfo uses makes no sense, there is no such thing as an "original frame rate". Both should match, period.

[malakudi]

Erik, read the link I posted, it explains what framerate and original frame rate means for mediainfo.

[Erik Slagter]

BTW: every other application (totem, vlc, ffmpeg, avprobe) report back 25 fps.

Yeah, they're probably all using libavcodec and libavformat for the probing, lol... FFmpeg report both, btw. Even more actually, it reports the frame rate in the container, of the codec and calculated from the timestamps.

[jbollacke]

BTW: every other application (totem, vlc, ffmpeg, avprobe) report back 25 fps.

Yeah, they're probably all using libavcodec and libavformat for the probing, lol... FFmpeg report both, btw. Even more actually, it reports the frame rate in the container, of the codec and calculated from the timestamps.

Ur probably right. So what does iServiceInformation in OpenPLi use?

Edited by jbollacke, 16 May 2014 - 09:40.

[Erik Slagter]

Erik, read the link I posted, it explains what framerate and original frame rate means for mediainfo.

Aparently what I call "fps information in the container" is called "default duration" in MKV terms. And MKV also has, like many other containers, an implicit frame rate, derived from the frames' time stamps. If the time stamps are incorrect in relation to the frame rate in the h264 stream, it's not going to work, no matter how it's called.

 

At some point this mkv has been muxed incorrectly, that's a fact. I think it's pretty hard to do so, maybe you can override the frame rate at some point (which would be a very stupid thing to do).

[jbollacke]

Erik, read the link I posted, it explains what framerate and original frame rate means for mediainfo.

Aparently what I call "fps information in the container" is called "default duration" in MKV terms. And MKV also has, like many other containers, an implicit frame rate, derived from the frames' time stamps. If the time stamps are incorrect in relation to the frame rate in the h264 stream, it's not going to work, no matter how it's called.

 

At some point this mkv has been muxed incorrectly, that's a fact. I think it's pretty hard to do so, maybe you can override the frame rate at some point (which would be a very stupid thing to do).

See this is a dubbed WEB-DL release. The video is 23.976 fps but the dubbed audio is for 25 fps video. So my explanation for this is that the group who releases these videos simply copy the video stream and override the timing information using the matroska container. It plays back fine everywhere @ 50Hz (even openpli, autoresolution disabled ) but autoresolution simply gets the wrong information to switch to. As the amount of videos like these will further increase as long as there will be some rules for this I think it is worth a fix to make it more fault-tolerance.

Edited by jbollacke, 16 May 2014 - 09:52.

[malakudi]

The correct way to do so is to speedup the H.264 stream, altering the timestamp of the H.264 frames.

[Erik Slagter]

Yes agreed, they're doing it the wrong way. You cannot change the timestamps only or the frame rate only.