Hello,
Dropped B-Frames beyond 2 consecutives.
Avidemux 261-r8449 zip (same problem on all previous I tried)
Cause : Mp4 Demux ?
Working on a H264 Mp4 HD file, I observe that Avidemux can't show more than 2 consecutives B-frame.
Browsing the video with right or left key it's easy to see, look at <Frame type> : never more than 2 B-Frame.
And <Time:> confirms the dropped one (000, 040, 080, 160!, ) ms.
Obviously, it appends when in low bit rate part of the video, like the tracking shot (the most irritating jolted results).
Avidemux can <Save> a <Copy> of a video cutting, free of default, no drop seen on media players.
But every try to re encode (x264), drops many frames, more or less. Or NOT, it depends on the original H264 video. Psss, so close to be so good ::).
Not a surprising result, thanks to avidemux window screen wysiwyg spirit.
Regards.
Please provide a sample
For Mean (working links attached),
I think these short files are representative.
Description in files title.
B-frames sequence are mostly in the looping.
Thanks, but I got a permission denied by uploader
It must be ok now. Use the new links.
Dropped B-frames, more precision :
- The problem doesn't exist if :
I work on x264.mp4 files encoded from Mpeg(s) files by Avidemux.
I use 4 Ref frame and 4 B-frame max, and all is fine.
- The problem is working on H264.mp4 files, mine anyway.
(I join 2 samples. They look like SD upscaling, yes, this part of the original is like that, don't worry.)
In a 3 B-frames sequence, it's not the 3rd B-frame that disappears but the 2nd.
The 1rst B-frame got a DOUBLE time length, taking the place of the 2nd.
In a 2 B-frames sequence no problem.
- I just start avidemux (8449), touch nothing, just load a H264-aac-1080p.mp4, that avidemux shows quite immediately, and start to browse left and right, frame by frame to observe that.
And it's not just a cosmetic problem, since If I encode, x264 or XVID or ââ,¬Â¦ , this part of the file, I 'got' these missing B-frames in the final Mp4 or AVI or....
Frame by frame with a media player ââ,¬Å"showsââ,¬Â the holes, I notice the missing frames.
In real world, the video is not fluent, like micro freeze, or 25 fps video jerking to 12 fps.
When the original is just ok.
For now, knowing that, I only work on Mpeg, or mp4 encoded by Avidemux.
Need a tool to check max B-frame of an external file before using it.
Using your samples, it seems the problem is not about encoding but about decoding
For an unknown reason yet, when decoding the input file, every 4 frames or so is detected as going back in time and dropper
i.e.
0 40 80 70 120 160
^ Dropped
So when encoded, there is a hole every time it happens
Checking what's going on
Yes Mean,
that's what I try to explain in the first post of this topic.
And also why I suspect the mp4 demux.
Happy to see somebody taking the time to understand something not evident to perceive.
Avidemux is so helpful anyway, so close to be so good.
Fingers crossed.
Anything else :
I try r8459
X264 'Quantiser' page has all value at zero by default.
It could be better to keep default value of r8449 for example, just great in any case.
Zero by default for Quantisers will lead to 10 Giga bytes for an hour encoded mp4 file (Big joke).
The pts of the 2 bframes are swapped
So instead of having
100 140 180 220
you have
100 180 140 220
Still looking why
So far it seems like the mp4 timings are incorrect
How did you create these files ?
I don't remember.
If you mean that the stroboscope of the running ball does not sound real on 'the original', you're right.
Rendering of the calculated move could be better.
But that's not the focus, isn't it.
The 'original' is a 25 fps all along (despite it is vfr capable), so timing between frame is a constant 40 ms.
- Load the file 'identical to original' both with Avidemux and for example Media Player Classic HC, side by side view.
Do a forward frame by frame, when the ball is in the loop (it's easier to see).
You will see that Avidemux drops some frames, MPC not, the missing frames we discuss on.
Where are these dropped frames ?
The 25 fps of the 'original', goes to a (25 fps Max, 12 fps Min) fps on the 'encoded' one (x264 encoder not involved it seems).
Due to missing frames ?
Again, half part of my H264.mp4 HD are well handled, but these ââ,¬Â¦ !?
-> I will join two other A and B files, a long regular panoramic shot (and regular drop got), from a DVB-T HD channel (France), witch do the same. Could they help.
About you're question, not sure what you mean by created ?
These 2 files were done by Avidemux :
A is a 'Copy'
B an 'Encode' of the 'Copy'.
Another try.
I record a DVB-T HD channel at the same time on two equipments.
One is .TS the other .MP4
There is no visible difference between them, frame by frame with MPC Media Player Classic.
MPC property for .TS :
Video: MPEG4 Video (H264) 1920x1080 25fps [Video - AVC (H.264), High Profile, Level 4.0, 1920x1080,
MPC property for .MP4 :
Video: MPEG4 Video (H264) 1920x1088 25.371fps [AVerMedia Video Media Handler - MPEG4 Video (H264) (eng)
There is a difference with Avidemux.
The.TS file is well handled, while the MP4 file has the B-Frame problem.
The problem is that , according to the file itself, the display order should be
I0 B1 B2 P3
But when decoding, the display order is I0 B2 B1 P3
So depending if you trust the timing of the file or the decoder you have all frames or some are dropped
I've checked the file and avidemux seems to do the right thing
I strongly suspect a bug, that's why i asked how the files were created.
It is either a bug in lavcodec/avidemux or a bug in the avermedia software when putting the timestamps on the frames
I think we can trust the file. Me be it use some unusual parameters.
Ref to my previous post,
MP4 file (avermedia) is as well played as the TS (direct record) by MPC-HC, with no dropped frame.
DXVA option in MPC-HC, no problem too with the MP4 file.
I also tried VLC player. No problem with the MP4.
Just one DVB-T HD channel from Avermedia, it seems so far, has MP4 problem with Avidemux.
Only Avidemux can't handle correctly MP4s of this channel.
Quite only, I have an Akira media player set top box which has also problems with these MP4s.
My Avermedia drivers and softwares are up to date 20-12-2012.
Below a link to a today file with more regular B-frames dropped sequence. HD channel with SD up-scaling, be aware.
http://rapidshare.com/files/845188533/D-file_H264_doing_avidemux_to_drop_B-frame.mp4
I'm not an expert on these. DVB-T is more sensitive to signal breakup/reception errors. If these occur nothing any hardware/software can do about it. I have dvb-t as backup reception just in case there is a problem with dvb-s. On DVB-T I regular glitches on reception. My dvb-t areal is 15 meters up (highest point of reception) and still have these issues.
So if there are errors in the stream and avermedia tries to compensate for these (filling in the blanks), that could explain the behavior) of this TS file.
Thanks for your interest.
Note : AverMedia delivers MP4, not TS, from DVB-T HD. TS are from other receivers.
I know that DVB-T can have breakup of all kind, and that's why Avidemux 2.6 is a so helpful, trust my user experience.
The problem is different here.
MP4 (AveMedia/PC) and TS files (set top boxes), from this DVB-T channel,
both have no error at all, played with MPC-HC, or VLC player, or a set top box.
Only Avidemux and 1 set top box have a problem with the MP4s of this channel.
And the problem is not just on a part of the file ( I chose an easy to see for you ),
but all along the video, every time there are more than 2 consecutive B-Frames, I did a random check.
It's too regular only to be breakup issue, I think.
That's why I think there is something to do with Avidemux/H264.mp4 and this kind of file.
I can't believe I'm alone with this problem.
I just tried Handbrake.
There is no problem on the re-encode result MP4 file with Handbrake, and so no breakout issue for sure.
You can try with the prior sample and see it by yourself.
So ... Sure there is a problem.
But Handbrake is not Avidemux !
Hello everybody.
I hope you don't misunderstand my remarks.
Avidemux is my favourite everyday tool.
It works so well on cutting joining re-encoding files of all kind, at least for me, that finding a bug, so far it is, is a surprise.
Like a mirror with one finger print.
You'll speak about the print cause there is no other thing to speak of.
For these stubborn files, I use Avidemux and another tool. And it's ok.
You see, even there, Avidemux join the party.
Thanks to provide for free this incredible tool.
ââ,¬Â¦ and be easy with my French accent.
Don't know if this is related to your issue? AVerMedia Game Capture HD Firmware Update for MP4 File Format Now Available (http://www.avermedia.eu/avertv/fr/Press/NewsDetail.aspx?Id=326)
Could be anything going on, usb issues, hardware bottleneck, non compliant mpeg stream. The transmission is mpeg-ts for dvb-t, whatever avermedia does with it? Don't you have a choice how the recording is made, mp4 or not?
If no solution is found: remember not to record that channel on avermedia and use other recorder.
No it's not related to my issue. Thanks.
My AverMedia drivers and softwares are up to date Dec-12 -2012.
I have tried previous version too.
For the specific problematic files I already have,
I use Avidemux to cut/join/export (copy.mp4) and any others H264 encoder with crop/resize filters to complete the job.
And it's OK.
The ' WYSIWYG ' defaults Avidemux shows with these files are not transmit when copying, only when re-encoding with it.
So, I have a convenient solution in any cases, with Avidemux.
B or b-frame in Open GOP situation, could it be the problem ?
Temporal order > Coding order
I used ffmpeg to convert the mp4 to mkv, which only contains pts
and i see exactly the same problem on the mkv
So, it is one of the two :
* Lavcodec borked the PTS when decoding : unlikely
* The file is wrong
I checked what mplayer does, no problem if timestamp are out of orders, it will manage
Could you run mediainfo on the mp4 file as it is created by avermedia ?
Especially the "Writting application" field if any ?
and can you play the original mp4 file with quicktime ?
With QuickTime 7, it's worst of all.
There are horrible forward/backward sequences instead of holes !
So I decide to compare the display of files and players, and it speaks you'll see.
- - - - - - - - - - -
I display an original (1) file with MPC-HC as a reference,
and I do a forward frame by frame comparing with other cases.
The players > MPC-HC(1.6.5) VLC(2.05) Avidemux(r8449) QuickTime(7)
(1) AverMedia-H264.mp4 OK (The ref) OK dropping back & forth
I display original file (1), as it is recorded by AverMedia from the problematic new entrant channel.
The result : with MPC and VLC it's fluent, no drop or what else. With AverMedia player, else ... too.
Avidemux and QT have problems.
(2) Avidemux Copy.mp4 OK OK dropping back & forth
I display a short cutting from (1), done with Avidemux (video and audio copy).
You know the file :
(http://rapidshare.com/files/845188533/D-file_H264_doing_avidemux_to_drop_B-frame.mp4)
The result is same as (1).
So Avidemux seems not affect the file, copy.mp4 of the cutting is usable, the same way as (1).
(3a) H264 re-encode.mp4 OK OK OK OK
I display a re-encoded H264 of (2) done with Hybrid (for examp.).
This way Avidemux, and QT, do like it.
(3b) Avidemux H264 re-enc dropping dropping dropping dropping
I display a re-encoded H264 of (2) done with Avidemux.
The file is corrupted now.
- - - - - - - - - - -
To summarise :
- Original mp4 file (1), and also (2), have all informations to be well displayed.
- MPC and VLC (at least) handle these files, when Avidemux not fully, and QuickTime goes crazy.
- Re-encode (1) or (2), solve the problem in every cases.
- But not when doing the re-encode with Avidemux.
I'll upload MediaInfo of (1) if you always want it.
And files 1 to 4 too.
I might an idea how to workaround this bug
(yes, I still think it's a bug in the application creating the file)
Try version > 8485 with preference -> trust timestamp -> partially trust
YES, you did it !
'Trust timestamp > partially' option is working (avidemux restart needed).
No more b-frame dropped !
Navigate the display screen is now as smooth as with mpeg. No more crash.
What I understand ...
in the chain, a link doesn't manage VFR, and drops frames.
Like demuxe .h264, bypassing the container .mp4.
As VFR Timestamps are in the container, copying is OK, re-encode.mp4 NOKââ,¬Â¦
What is confusing is the display screen lets assume video is always CFR.
- Information panel > Frame rate, at least show CFR or VFR, to be advise and decide.
'Trust timestamp partially' Hum, so it does not sound complete ?
Is it a single vfr issue, do you enforce cfr (unlike), do you deal with vfr/buggy writing, can you explain a little the option ?
So far, 'B-frames dropped' in x264.mp4 seems solved, let me work on some various files to check it.
Flat singer.
r8485 do not handle anymore x264.ts
Sound is chopped ~ 0,5Hz
( See Post 19 above :
There is a difference with Avidemux.
The.TS file is well handled, while the MP4 file has the B-Frame problem. )
> Now it's reverse :
r8485 manage x264.mp4 (vfr), but not x264.TS (chopped sound).
I dont hink i have the .ts, could you (re) post a link to it ?
In fact, it's a new problem in TS.
Chopped (~ 5 Hz ) sound in .TS appears in r8467 (or just below, 8459 is ok).
I use r8449 up to now, so I can't be aware of this problem.
All (~?) my HD H264.TS have chopped sound in r8467 and above (load TS files in Avidemux and play).
- the ball (I don't find the children)
http://rapidshare.com/files/1345991017/Avidemux_Copy_cutting_(identical_to_original).ts
http://rapidshare.com/files/636878598/Avidemux_Copy_cutting_(identical_to_original).mp4
- and a random one :
http://rapidshare.com/files/1648853868/Chopped_sound_r8467AndUp_(r8459-OK)_F2HD-120914.TS
Most probably due to ffmpeg update
They switched from interleaved to planar channel layout, i have to update the code
They switched to complexity, to have flexibility (?)
Should be ok now
YES, r8494-x64 navigates and plays h264.mp4 (pop up Yes) and TS, those of the topic and some others.
To re encode h264/aac.mp4:
- FAAC is no more there, Lav don't want e-ac3 (?).
- And it uses only 20% cpu power (i5 2500K), first time seen.
Prior Post was obviously for '8494 nightly'.
Release 8494 seems doing the job. I use it.
I just disable Weihted Prediction for P-frames to ensure compatibility with 'old' set to box, and that it.
Afaik, I don't see anymore dropped frame now, don't forget to chose the right option when pop up.
When a file has evident errors (square pixels, light freeze), Avidemux deals nicely these videos, thanks 2.6.
Nice looking results now, in a couple of clics.
Thank you so much.
I not only use h264/aac.mp4 with Avidemux, but it's 60% of my videos, I will have to use it heavily and let you know.