April 13, 2021, 01:36:56 AM

News:

--


25fps videos seen as 50

Started by twinsun, March 30, 2015, 07:08:02 PM

Previous topic - Next topic

twinsun

25fps videos seen as 50

Avidemux opens some 25 fps videos as 50 fps (see Information menu).

A sample, just edit/copy into mkv, gives a right 25 fps video, yet.
But encoding (ie resize) into mkv, gives a marked 50fps video (?).

Some players don't like the result, the video (still 25fps) is played 50fps as marked, when the audio is at good speed (25).
Others, play it right (apparently).

Org, 25 fps :
https://drive.google.com/file/d/0B7UOzqUbGLumR1NVSzR3ODBsWlE/view?usp=sharing

Result (ie) :
https://drive.google.com/file/d/0B7UOzqUbGLumYVVhUXlodmVrcms/view?usp=sharing

Jan Gruuthuse

Mediainfo shows both files as being 25 fps
As you you indicated both do play fine over here (vlc). VLC is showing in codec Frame Rate 50.
Perhaps other players have more issues with the resized video?
- 1920 by 1080 (source)
- 1312 by 720 (resized)
While probably some players expect 1280 by 720
Another issue could be that some players have issues with E-AC-3
Or the combination of the 2

twinsun

There is nothing to do with e-ac3 or frame size, or even the source .mts .
All my players (box, xbox, mpchc, vlc, ampli video, ) handle e-ac3 and run any kind of frame size in real size.

The problem here is that avidemux opens the ââ,¬Å"Org, 25 fpsââ,¬Â video as a 50fps one (clic avidemux ââ,¬Å"Informationââ,¬Â to check).
Then, depending on what you will do on the file, the resulting video wil be tagged 50fps, else it will be 25 in real.

Good players detect the real 25 fps, going over the 50 fps tag.
MPC-HC ââ,¬Å"propertiesââ,¬Â indicates 50 fps on ââ,¬Å"Resultââ,¬Â video, and plays it at 25, it seems.
But some play the video as it is tagged : 50fps. The video is obviuosly displayed as it was accelerate x2, while the audio is at just perfect reel speed (as 25).

So I think it is a simple fps detection problem at the opening (demux in avidemux), in some cases.
Anyway, tag a video 50fps when it is 25 is a problem in itself.

Aside : about 1920x1080 and 1312x720 (definitely not the problem here)
ââ,¬Å"Orgââ,¬Â has black sides, so the crop and resize 1/1 give a 1312x720 video, the reel aspect ratio of the reel video.
I resize the video cause it is obviously an upscaled one, and 720 is even far to high regarding the source quality.

Jan Gruuthuse

March 31, 2015, 02:20:42 PM #3 Last Edit: April 16, 2015, 05:22:53 AM by Jan Gruuthuse
A little hard to understand if there is no issue here.
Anyway you can solve this issue with mkvtoolnix:
load video in to mkvmerge
select video track
in format specification change to 25 fps
start muxing
adjusted fps: (H264_DD+_25ips) edit&resize720.mkv download

AQUAR

Maybe its because this video contains interlacing and the 50 fps tag informs of the presence of 50 fields per second.
Seems to me its a situation where some media players don't get along with MBAFF.

If ADM playes it back at the correct frame rate, and shows the tag info correctly (50 fps!), then this is just user misinterpretation of the source material.

twinsun

Two points, one good, one BAD (just discovered):

1 - Great, mkvmerge solves the ââ,¬Å"fps issueââ,¬Â.
The Result video is well played everywhere (now 25).

2- Avidemux crops the video from the bottom at just the opening (24 lines missing).
Avidemux crops the video from the bottom at just the opening (24 lines missing).
ââ,¬Å"Orgââ,¬Â video is, yes, 1920x1080, but Avidemux Information shows 1920x1056 (?), and works on this.
That's why the Result video is 1312x720 instead of 1280x720 in a 1/1 ratio sheme.

In fact all 1920x1080 videos I have just checked, are opened 1056 or 1088 height.
It's a modulo 32 issue it seems.
In 1088 cases, avidemux has add 8 lines at the botton.
Lines I was used to crop, without wondering why the video had these.

Distressing issue, since I had never thought to verify this kind of basic information.
If confirmed, I'll open a new topic on it. 

Jan Gruuthuse

April 04, 2015, 03:16:09 AM #6 Last Edit: April 04, 2015, 05:37:46 PM by Jan Gruuthuse
Fixed by commit 6f1d8cd    [ffmpeg] crop is in pixel, not in mb
Confirmed current avidemux 2.6.8 now sees 1920 by 1080 as 1920 by 1056.
Trying to trace back when this was introduce.
20140901 db007351699 OK
20140902 4bd8529dbc1 OK
20140903 4468e4db082 OK
20140904 32fbeac52bf OK
20140905 85f9985660a OK
20140914 f699f798637 OK
20141012 725dcd87455 NOT TESTED: wont load mpeg-ts hd stays in loop
20141019 afc4f2121bf OK
|
This is introduced somewhere between 19/10/2014 and 13/12/2014. I don't have builds in between to test.
|
20141213 75df0921043 not OK


mean

Probably  an update to ffmpeg

Jan Gruuthuse

Could be, myself have no idea at all.

mean


Jan Gruuthuse

April 04, 2015, 05:36:14 PM #10 Last Edit: April 04, 2015, 05:42:00 PM by Jan Gruuthuse
confirmed: today's build 6f1d8cd    [ffmpeg] crop is in pixel, not in mb.

reports back 1920 x 1080

thanks, Happy Easter


twinsun

Great.
1920 x 1080 fixed confirmed, on above sample and various kind videos.
Have not to forget to recreate previous idx2 index, if any.

Thanks to AVDM team, again.

twinsun

No more 1056, but got a 1080 viewed 1088.
Croping the too much lines makes it workable, but can hide issue(s). Sample :
https://drive.google.com/file/d/0B7UOzqUbGLumRHlFWE5ubklBTWc/view?usp=sharing

Jan Gruuthuse

avidemux and mediainfo report 1088, vlc and handbrake not :( 1080

twinsun

Sure you got the situation, but for those who don't :
If you look at the bottom of the above 1080 sample (ie), opened in the AVDM window, you will see the 8 lines added to the 1080 (line 1080 is duplicated 8 times).
My 1080 videos (sure they are), are AVDM opened ~ half 1080, half 1088. I don't know why at my level.
Of course, these 'virtuel' lines don't exist when you play these files with MPC-HC, VLC, box ...

To go over this issue in all cases in present state, if you see 1920x1088 in AVDM 'Information' :
- Cropping the 8 lines when editing (resize or what else) to reencode, fix it.
     !! If you don't crop (never I forget) : your new file while be affected by these 8 added lines.
- Editing with no reencoding : you target file will not be affected, still being 1080 like the source.