Merge Fields bug

[bjohnson777]

I'm using 2.6.8 on Ubuntu 14.04 LTS. I've also seen this problem using 2.6.1 (and another version I can't remember since the upgrade) on Ubuntu 12.04 LTS.

I believe this bug to be easily reproducable by others, so I'll give the quick steps. If it isn't the case, I'll dig in and post details from the log files. Note that after the crash I can't find admlog.txt, but crash.js does show up as expected.

30 seconds of steps to reproduce:
Launch a 2.6.x version.
Load any video clip. Doesn't matter type.
Set video output encoding to x264. Type doesn't seem to matter. Accept default settings.
Load filter "Interlacing / Merge Fields".
Load filter "Interlacing / Decomb telecide." Accept default settings.
Load filter "Transform / Crop".
At this point I always get a crash.

The info window reads:
Crash

Assert failed :0
at line 176, file /build/avidemux2.6-iCxcSA/avidemux2.6-2.6.8/avidemux_core/ADM_coreVideoFilter/src/ADM_videoFilterCache.cppADM_backTrack
VideoCache::getImageBase(unsigned int)
VideoCache::getImageAs(ADM_HW_IMAGE, unsigned int)
Telecide::getNextFrame(unsigned int*, ADMImage*)
ADM_flyDialog::nextImage()
Ui_cropWindow::Ui_cropWindow(QWidget*, crop*, ADM_coreVideoFilter*)
DIA_getCropParams(char const*, crop*, ADM_coreVideoFilter*)
CropFilter::configure()
ADM_vf_addFilterFromTag(IEditor*, unsigned int, CONFcouple*, bool)
filtermainWindow::allDoubleClick(QListWidgetItem*)
QMetaObject::activate(QObject*, QMetaObject const*, int, void**)
QListWidget::itemDoubleClicked(QListWidgetItem*)
QMetaObject::activate(QObject*, QMetaObject const*, int, void**)
QAbstractItemView::doubleClicked(QModelIndex const&)
QAbstractItemView::mouseDoubleClickEvent(QMouseEvent*)
QWidget::event(QEvent*)
QFrame::event(QEvent*)
QAbstractItemView::viewportEvent(QEvent*)
QCoreApplicationPrivate::sendThroughObjectEventFilters(

If I just use the filters "Merge Fields" and "Crop", the video fields will be interlaced with double height as expected. "Decomb telecide" seems to have some kind of issue when added.

The goal of the rendering is to turn a 720p 59.940fps TV recording into a 480p 23.976fps x264 file. 23.976fps is the original frame rate of the source before broadcast TV bastardizations.

Thanks for the help.

[ajschult]

The crop filter config window is trying to produce a preview image to let you select the crop; the retrieval of the image goes through the telecide filter and fails.

Before the assertion, the code prints some info about what went wrong:

Code Select Expand


  [getImageBase]  Cache inconsistency :
  [getImageBase]  Expected to get frame 1 from filter, got frame 0 instead
Entry 0/16, frameNum 0 lock 2 lastUse 1
Entry 1/16, frameNum -65536 lock 0 lastUse -65536
Entry 2/16, frameNum -65536 lock 0 lastUse -65536
Entry 3/16, frameNum -65536 lock 0 lastUse -65536
Entry 4/16, frameNum -65536 lock 0 lastUse -65536
Entry 5/16, frameNum -65536 lock 0 lastUse -65536
Entry 6/16, frameNum -65536 lock 0 lastUse -65536
Entry 7/16, frameNum -65536 lock 0 lastUse -65536
Entry 8/16, frameNum -65536 lock 0 lastUse -65536
Entry 9/16, frameNum -65536 lock 0 lastUse -65536
Entry 10/16, frameNum -65536 lock 0 lastUse -65536
Entry 11/16, frameNum -65536 lock 0 lastUse -65536
Entry 12/16, frameNum -65536 lock 0 lastUse -65536
Entry 13/16, frameNum -65536 lock 0 lastUse -65536
Entry 14/16, frameNum -65536 lock 0 lastUse -65536
Entry 15/16, frameNum -65536 lock 0 lastUse -65536


[mean]

The telecide filter is incomplete, i should disable it
Actually it's going to be better as we can rely on timing to deal with mixed format i.e. progressive with 3:2 pulldown and telecine content

[bjohnson777]

Is there a workaround to get 59.940fps back to 23.976fps for now? With a TV source, I run into audio sync problems in other programs because of commercial breaks and different frame rates.

Thanks

[zakafreakarama]

I know it's probably not an optimal solution, but I got pretty good results by using the FFmpeg deinterlacing filter (under libavcodec deinterlacers) and then Decomb Decimate. I got a sharp, progressive, 23.976 fps picture. The source was telecined film material (music videos) and Decomb Telecide just didn't do the job. I didn't merge fields or anything else, just applied the FFmpeg deinterlacing filter and Decimate. And the results were surprisingly good.

[bjohnson777]

Thanks for the tip, but it won't fix the frame rate issue. It amazes me how the "TV Engineering Associations" came up with something as screwed up as frames to fields at twice the frame rate for digital TV... and interlacing still lives at other frame rates... when it shouldn't in the digital realm. As it stands right now, the raw file plays 1 frame, 2 dupe frames, 1 frame, 1 dupe frame, repeat... for 59.940fps. Since all digital TV's are basically mini stand alone computers, they can play at any frame rate just like a computer does. There is no "sync to signal" like back in the analog days. The original HD could have easily been broadcast at 23.976fps at the same overall bitrate with better picture quality and the TV could have handled it fine and nobody would have noticed the frame rate difference... That's my rant for the evening.

I've gotten tolerable results with Decomb Telecide and Decom Decimate at normal frame rates using very sensitive settings. Mean mentioned the filter was incomplete, so that probably explains a video skip every now and then. It was good enough for what I wanted to do at the time.

[bjohnson777]

I had an idea for a test last night after posting. Since double frame rate is already decombed in terms of interlacing, why not run Decomb Decimate at 2 and see what happens? The output was at the expected 29.970fps from 59.940fps, but to my surprise, the sequence turned out a clean 4 frames and 1 dupe... standard telecide. Just for fun, I ran Decomb Decimate at 3 and the output was an expected mess.

Since Decimate 2 worked, adding Decimate 5/Pulldown Dupe Removal turned 29.970fps back to 23.976fps.

The results were good, but not perfect. While each frame was proper original, losing essentially a half frame of motion blur makes the video slightly choppy. It's not overly noticeable unless you've done video engineering in the past. It's good enough for most general renders.

This method is best for scaling down the image size since some vertical resolution is lost with Merge Fields missing. I don't recommend the following for the original video size.

Here's something for the archive in case someone else also runs into this problem in the future...

Converting Double Frame Rate HD Video Back To Normal Using The Double Decimate Method

• Add filter Decomb Decimate, Cycle=2, Discard Closer. This undoes the double frame rate.
• Add filter Decomb Decimate, Cycle=5, Pulldown Dupe Removal. This converts the frame rate back to film. There should be no extra dupe frames after this filter.
• Optional: Add filter Crop to remove any trash around the edges of the video.
• Optional: Add filter EQ2, Gamma=1.2, Color Saturation=1.2. This tends to get the Black Levels out of the mud. For really dark videos, bump the values up to 1.4.
• Add filter SWResize, Aspect Ratio Lock=On, Source and Destination=16:9 (choose 4:3 for non wide screen), Round to 16=On, Size Height=480, Method=Lanzcos3. That should give a Width of 848. While h.264 can support other resolutions, it's best to keep the width and height multiples of 16. Older xvid/divx and mpeg2 require multiples of 16. For a smaller resolution maybe needed by a portable device, try 400p or 352p in the Height box. A quick word on Aspect Ratio: It's OK to be a little off when selecting width and height and also removing a little using Crop. Humans can't see small errors. The physical screen size may also not be perfect. It's OK so long as a circle looks like a circle and a square looks like a square. I don't know why some people blow a gasket on this issue.
• Finish out any video codec, audio, and container settings then start the render.

While mentioning Black Levels, can one of the developers get the Luma Equalizer filter ported to 2.6.x? I find it very useful for fixing dynamic range problems and would include it in the above list after Crop if it were available.

[AQUAR]

Just a comment about a tangent on this discussion.
Video rendering onto PC screens (or Digital TV's) have sync related graphics processing parameters as well.
The film rate of 23.976 fps is not a match for 50Hz or 60 Hz screen refresh rates of typical digital TVs, but not bad for a PC monitor set to 72 Hz.
Graphics cards will have to do frame interpolation, or drop frames, or manipulate the source in other sophiscated ways to create "virtual sync".

Just food for thought about converting videos for digital displays. 

[mean]

It was a bug in mergeField

[bjohnson777]

Aquar: Yeah, but most graphics cards will double buffer and play the video frame at the next graphics frame interval. Otherwise there would be "video tearing" when played back. 23.976 and 29.970 NTSC on a 60Hz TV would have the same issue. The "video jitter" produced by that isn't within human visual perception. Last I looked, most HD TV's were starting to have >100Hz frame refresh rates... but I haven't looked recently. Not sure if that's all of them. That's kinda pointless for TV related, but it is useful if a computer or game console is hooked up to them.

Mean: Any idea when the bug will be fixed? Thanks.

[ajschult]

mean already fixed it:

https://github.com/mean00/avidemux2/commit/6965bf8f0d23cba1a233b25b8523ac73d21b2a9c

(no crash for me, at least).

[AQUAR]

@ bjohnson777
Always understood that tearing may occur unless the double buffer swap happens during vertical blanking.
That only happens all the time if the refresh rate is an integer multiple of the video frame rate.

I think without this, the drawing to the back buffer will be part way through rendering a frame when the monitor does a screen refresh.
The graphics card will then do the buffer swap and send mixed frame content to the monitor.

As you said though, delaying the swap till the next frame interval wil fix the tearing and give some jitter (and frame drops!).
Current graphics cards will do smart interpolations to smooth things out but thats too involved for me.

[bjohnson777]

ajschult: Thanks for the update. Tracking bugs is a bit above me.

Mean: Thanks for the fix. I'm going to try a compile this weekend.

[bjohnson777]

My usual upgrades found that getdeb released 2.6.9 today.

I loaded Merge Fields in the filter list without problems. I ran a full render, but it crashed and didn't save out a video file... not even a partial.

I dropped the rendered video segment to a minute and used that for other tests. Sometimes it will crash at the start with an empty Info window. Sometimes it will render all the way through the second pass, but it always crashes at the end and disappears without a crash file or Info window. When it makes it this far, sometimes it saves the video and sometimes the video is totally missing (but the stats and mbtree files will be there).

I removed Merge Fields from the top of the filter list with no behavior change. Decomb Telecide was next. Getting rid of that seems to have stopped the crashes.

Attached are the shell window and crash file. This is when 2.6.9 crashed immediately on hitting save after entering a file name.

I found the 2.6.x compile instructions off the download page, but the instructions are for the older SVN setup. What's the download instructions from git?

Thanks

[bjohnson777]

Doing a little digging around, I took zakafreakarama's advice with "libavdec Deinterlacers / FFmpeg Deint" in place of Decomb Telecide. It does work surprisingly well and the test video renders without crashing.

What got me side tracked the past couple hours was the video was more jerky on play back than the Double Decimate method I mentioned above. I went through it frame by frame on many different settings but couldn't see anything wrong. The frames were consistent on pans and didn't jump around.

On a whim, I added "Resample FPS" to the end of the filter chain and set it to "23.976 Film". With the video already being 23.976fps, this shouldn't have made a difference at all... but it made a huge difference. Suddenly motion was fluid like it was supposed to be.

Thinking something was up with MKV, I swapped encoding to xvid/avi. I used the filter chain as before without "Resample FPS". The test render came out smooth.

I know that AVI is old and brain dead... which is kinda why I like it for older codecs... But does this mean that MKV can support essentially "Jitter Frame Rates"???

I tried a simple MKV to MKV remux with mkvmergeGUI with a forced video frame rate of 23.976. The video became smooth again but it suffered from audio sync and slow skews leading to a larger sync problem at the end of the video. I'm not sure what to make of the audio issue with mkvmergeGUI. The frame rate in the program video is a clean multiple to decimate back to 23.976 and should have worked cleanly with mkvmergeGUI. I cut out all the commercials and promos that would have given constant frame rate errors.

As a side note, "Resample FPS" has a simple bug of only allowing 2 decimal places in Custom when it should allow for 3.

I'm going to re-render the full video in 2.6.9 to see if there are any audio skews that won't show up with a 1min test render.