X264, dropped B-Frames beyond 2 consecutives ?

[Jan Gruuthuse]

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.

[twinsun]

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.

[twinsun]

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 !

[twinsun]

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.

[Jan Gruuthuse]

Don't know if this is related to your issue? AVerMedia Game Capture HD Firmware Update for MP4 File Format Now Available
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.

[twinsun]

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.

[twinsun]

B or b-frame in Open GOP situation, could it be the problem ?
Temporal order > Coding order

[mean]

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

[mean]

Could  you run mediainfo on the mp4 file as it is created by avermedia ?
Especially the "Writting application" field if any ?

[mean]

and can you play the original mp4 file with quicktime ?

[twinsun]

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.

[mean]

I might an idea how to workaround this bug
(yes, I still think it's a bug in the application creating the file)

[mean]

Try version > 8485 with preference -> trust timestamp -> partially trust

[twinsun]

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.

[twinsun]

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).