News:

--

Main Menu

Merge Fields bug

Started by bjohnson777, May 10, 2015, 06:20:29 PM

Previous topic - Next topic

bjohnson777

My mesa/vdpau are different than yours:
ii  mesa-common-dev                            10.1.3-0ubuntu0.4          amd64                      Developer documentation for Mesa
ii  mesa-vdpau-drivers:amd64                   10.1.3-0ubuntu0.4          amd64                      Mesa VDPAU video acceleration drivers
ii  mesa-vdpau-drivers-dbg:amd64               10.1.3-0ubuntu0.4          amd64                      Debugging symbols for the Mesa VDPAU video acceleration drivers
ii  vdpauinfo                                  0.1-1                      amd64                      Video Decode and Presentation API for Unix (vdpauinfo utility)


Edit / Preferences / Display: from VDPAU now to Xvideo.
Horizontal / Vertical Deblocking now off.
OpenGL was already off.
HWAccel / AMD: now off.
Threading: from 5 to Auto. Note that rendering usually won't take up all 4 cores in my quad, so I set it to 5 generally.

For the terminal program, depends on which you use. I just open a shell and run avidemux3_qt4. I've been using various flavors of unix forever, so shell comes natural to me.

Looks like my fuzzy eye sight problems and being chronically sleep deprived made me miss the dropbox option. Sorry about that. I understand what you're saying about the breakup issues with "Direct Strem Copy" as it was called in the VirtualDub days. I used to analog capture to xvid/avi (and still do for my other analog cap card). Clipping out the trash on keyframes was mandatory for AVI.

I deleted the idx2 file before, but I just deleted both (for main.ts and test.ts) again.

I started an xvid/avi test render last night before bed. It still crashed at the end of the first pass. I can post the crash.py and shell.log if desired. Probably not since I'm running another test with the above preferences settings I'll post before bed.

Back to tinypy...

I haven't run into "Crop" crashes with 2.6.9. I find that odd. That may have something to do with a different video source. I don't have much to render now besides the main.ts and test.ts (taken from main.ts) files.

When I'm rendering down to a smaller size, I usually will crop a tiny amount off the 4 sides to make sure excess black bars or junk doesn't get through. In this case -2 for each side. Avidemux requires the crop amount to be an even number.

Remember my HD video is 2x height from the MergeFields filter. The raw mpeg2.ts file is 1280x720 double frame rate.

I sometimes get questionable numbers from swsResize. The main key when rendering down to 480p is the "848x480, algo2" entry at the end. If I open swsResize, the "auto" functions tend to screw everything up and becomes a fight.

Looking at your filter list picture:

Mplayer EQ2: Sat should be 1.20. Boosting chroma is needed a little when boosting gamma to get the video out of the mud. I doubt that matters for this test, though.

Using bjohnson777.py on my usual test.ts file I've been using here, opening Crop didn't cause a crash for me. The 1min file rendered out normally.

From the main.ts crash using the new preferences:
command run from shell: avidemux3_qt4 2>&1 | tee shell.log
I did a "man tee" and discovered it doesn't redirect stderr, so I have that fixed tonight. Sorry about before.

New crash.py and shell.log attached. I used the tinypy project file I posted the other day without changes.

Thanks for the help.

Jan Gruuthuse

Now comes the weird stuff.
- Load 720p video
- run bjohnson777.py script
- save video: avidemux 2.6.9 crashes.

Next:
- Load 720p video
- run bjohnson777.py script
- goto Video: Filters, preview each filter
- save video: no avidemux crash

Hope developer(s) have a clue/idea why this (c/w)ould happen.


Jan Gruuthuse

Terminal output from crash without each filter preview

mean

I strongly suspect decimate

bjohnson777

For git-150531, following Jan's steps, I get random crashes. It probably has something to do with start and stop frames on mine as my test.ts is longer than I want so I clip it to 1m9s.

Using my tinypy project file that already has the start and stop frames fixed, the test.ts file will always render. Changing the start and stop frame positions is the first time I've seen test.ts crash.

What are the next steps I need to do?

Thanks guys.

Jan Gruuthuse

proposal:
- edit/cut with video and audio in copy, middle sections first.
- don't edit Start and End of video. This should be last step before saving the new video:
-- mark with [A ]on key frame where you want to start new video
-- mark with [ B] where you want to end the new video
- now save video
- apply filters to new video and re-encode that video.
See if that works for you.
All I could think of from my side.

bjohnson777

I think I'd also run into crash problems with that method, too. If the problem is decimate based as Mean suggests, getting a successful render will be highly dependant on which frame is left in or out and where each frame starts in a cut section... and maybe if there's a minor blip in the raw mpeg2.ts file that throws things off a little.

I guess next step is to wait for a developer to track the problem down now that it is defined. Someone please post to this thread as I don't follow git and a new post will alert me of a change.

Thanks guys

bjohnson777

Any luck on tracking down the crash problem? I did a fresh compile from git last night followed by the same render as before. It crashed at the end of the first pass with an empty "info" pop up box like always.

Thanks