Video sync or field issues

[Jan Gruuthuse]

Have a weird situation:
- videos edited with avidemux 2.6.10  0d807cd
- Lavcodec, Video display XVideo (best), no HW Accel
- source mpeg-ts 1920ix1080, both video and audio with copy, cut on key-frames.
End Result plays correctly on computer, no longer plays correctly on flat screen Samsung UE40B8090XP (2009)
At the screen right hand part from the middle of the screen onwards, other frames flash up. This occurs in .MKV container, not in .TS container
Perhaps End Result video gives you more info on what is going on:
- MasterChefImageBreakups.mkv (7 MB) <- not OK on UE40B8090XP
- MasterChefImageBreakups.ts 7.9 MB <- OK on UE40B8090XP
- Start of original recording, not that fragment 12.6 MB

[mean]

If you remux it with mkvtoolnix, does it work better ?
It could be a limitation on the flat screen (?)

[Jan Gruuthuse]

When avidemux produced mkv is remuxed with current mkvtoolnix gui: it gets like in slow motion, bitrate seems to drop. No it worked all those years before, its only recently happening.
I'm now tesing against todays built

[Jan Gruuthuse]

No, issue still there. The avidemux produced .mkv show also only 1/2 height (like zoomed in).

[mean]

Probably need to indicate it is field encoded in the mkv header

[AQUAR]

@ Jan, Mean

Just in case it holds some clue.
Tried to play the "not ok" sample with windows media player.
It fails with a run time error when using ffdshow codecs (ffmpeg-mt or libavcodec).
Using the MPC-HC codec (also uses ffmpeg!), or the Microsoft codec, the file plays fine.
 

[mean]

does it help if you do on the file generated by avidemux :
mkvpropedit -e track:v1 -a interlaced=1 thefile.mkv

[Jan Gruuthuse]

Sorry, no it did only produce unsupported video. With Yesterdays build I lost lavcodec to process mpeg-ts bbc HD. Terminal window closes with in titlebar:

[initUI]  Muxer, creating UI, video duration is 00:00:08,080
*** Error in `/usr/bin/avidemux3_qt4': free(): invalid pointer: 0x0000000004271930 ***

Code: [Select]

[initUI]  Muxer, creating UI, video duration is 00:00:08,080
*** Error in `/usr/bin/avidemux3_qt4': free(): invalid pointer: 0x0000000004271930 ***without creating crash file or log.
I'm going to revert to earlier versions and see where it still works.
going back to before:
- 19 Jul c551b44
probably will test this one 1st:
- 10 Jun 329d81e        [build] not release

[AQUAR]

For me, the behaviours I noted previously, stays the same when you set that MKV header flag.
Except that mediainfo now determines the frame rate based on the field duration (frame rate went up from 25 fps to 50 fps!).

I was originally thinking there may be some issue in the way this sample mkv is interpreted by older versions of codecs/containers (since ffdshow is pretty old on my PC).  And that this may also be happening on Jan's Samsung TV.
It was only a thought and probably way off the truth.

Only other things I can add is that a visual c++ runtime error dialog pops up.
The event log shows that the faulting module is the ffmpeg.dll.
And this also happens with the TS sample (obviously and unlike Jan's issue).

On my other PC this issue doesn't even exist (different codec versions).

Ah well - endusers 2 cent's worth!!!! 

[Jan Gruuthuse]

Still trying to put my finger on this.
I suspect this could be Lavf related. I tried avidemux 2.6.10, 2.6.9 and have on the spare computer 2.6.8 all avidemux build Lavf56.25.101. If I'm reading my tests correctly.

The only mkv's playing correctly are:
- one playing (probably done with avidemux Lavf54.63.104)
- one playing (Handbrake 7412svn Lavf56.1.0)

I see mean has new submit, I'm now building that one and test soon.

[Jan Gruuthuse]

sorry, 150907_3e97953b851 still produces the issues with mkv.

[AQUAR]

Well, this one "re-encoded Lavf56.1.0: handbrake mkv 37.6 MB" also plays fine using the "old" ffdshow codecs.
But unfortunately it seems to be a progressive coded sample as opposed to the interlaced coding of your original sample.
Probably more useful to stay with interlaced AVC samples?

One thing that does kind of seem odd is:
I thought that AVC uses MBAFF for interlaced content and Mediainfo normally picks that scan type.
But with your original sample it shows the AVC as having a scan type of "interlaced" in lieu of "MBAFF".
Not sure if setting the fake interlacing flag would present it that way?
Not done much AVC encoding so no experience with that (I think the faking is used for segmented progressive frames?)   

I think only mean has the expertise to find out what/where some deleterious change has snuck in. 

[Jan Gruuthuse]

A little frustrating and starting to doubt myself, so tested again. Not re-encoded: audio and video both copy in avidemux to mkv. Remuxed source with mkvtool nix gui
avidemuxed is only playing visual top half (like zoomed) on samsung flatscreen
mkvtoolnix plays correctly when source video is passed directly through
Each download is approx. 35 MB, the mpeg-ts you probably downloaded already, did not change.
- mpeg-ts source: BBC One HD - Homes Under the Hammer
- mkvtoolnix gui: mkvtoolnixgui.mkv
- avidemux 2.6.10  (77bda88): avidemuxed.mkv

update: The only main difference I can see:
avidemux  : Frame rate mode                          : Variable
mkvtoolnix: Frame rate mode                          : Constant
could this be enough to cause that issue?

[AQUAR]

Don't think that would be the cause as that info isn't held in MKV (I think).
For MKV files, Mediainfo just samples the frame duration and predicts if its constant or variable.
Can be that the first couple of frames have had their duration "adjusted slightly".
If so Mediainfo will report variable when 99.99% is actually constant.

The reason I mentioned MBAFF, is that this is normally the scan type for AVC video with interlaced content.
But your AVC/TS source, when avidemux remuxed (using copy mode, see masterchef mkv sample), showed the scan type as interlaced not MBAFF (in Mediainfo).
Maybe that upsets the decoding?

I know that it also doesn't play on my PC with older versions of the codecs/container (parsing).
Possibly a clue in that but its beyond me.
 

 

[Jan Gruuthuse]

Most likely that work flow test was flawed. (mpeg-ts -> avidemux -> mkvtoolnix) (sbs6).
Now tested (both showing MBAFF):
Original recording on STB (mpeg-ts) -> avidemux (copy for video and audio) to mkv. avidemuxed not playing correctly on samsung (only top half showing in on fullscreen).
Original recording on STB (mpeg-ts) -> mkvtoolnix (copy for video and audio) to mkv. mkvtoolnixgui playing correctly on samsung.