Username:
B
I
U
S
"
url
img
#
code
sup
sub
font
size
color
smiley
embarassed
thumbsup
happy
Huh?
Angry
Roll Eyes
Undecided
Lips Sealed
Kiss
Cry
Grin
Wink
Tongue
Shocked
Cheesy
Smiley
Sad
<- 1  -   of 38 ->
--
--
List results:
Search options:
Use \ before commas in usernames
Okay, I didn't realize that it already does that.
The Dork Knight himself.
I'm not sure how feasible this is, but could there be a way to automatically load/append videos that get split into parts by stupid programs?

I've been recording using nVidia's Shadowplay, and due to a limitation in Win7 (and probably nVidia laziness) all of the files are broken up at the 3.8GB mark. The files are named like this:
Batman  Arkham City 02.17.2015 - 22.34.22.07.mp4
Batman  Arkham City 02.17.2015 - 22.34.22.07_1.mp4
Batman  Arkham City 02.17.2015 - 22.34.22.07_2.mp4
etc etc

If I try to load a file and type a name with a wildcard at the end (Batman  Arkham City 02.17.2015 - 22.34.22.07*) I'll get every video in the sequence. What I would like is a way (without commandline preferably) to have Yua automatically find all of the pieces and append them in sequence. For a 2 hour run I can have up to 10 chunks which get annoying to add manually (god forbid I choose the wrong video in the sequence). Even if I'd have to dump all of the corresponding pieces into a separate folder it would make things much easier.
have you tried selecting more than one file when you go to append?
Edit history:
Mystery: 2015-02-24 02:36:53 pm
Quote from honorableJay:
I'm not sure how feasible this is, but could there be a way to automatically load/append videos that get split into parts by stupid programs?

I've been recording using nVidia's Shadowplay, and due to a limitation in Win7 (and probably nVidia laziness) all of the files are broken up at the 3.8GB mark. The files are named like this:
Batman  Arkham City 02.17.2015 - 22.34.22.07.mp4
Batman  Arkham City 02.17.2015 - 22.34.22.07_1.mp4
Batman  Arkham City 02.17.2015 - 22.34.22.07_2.mp4
etc etc

Apparently this is a limitation in Windows 7 because nVidia uses the internal Windows 7 MP4 muxer. Interestingly enough, this problem does not exist on Windows 8+.
So I suppose it could be called nVidia's laziness and Windows 7. If they'd just used a mkv muxer, the problem wouldn't be there...

You can also use mkvtoolnix to merge files to an mkv file and then encode that, I suppose.
The Dork Knight himself.
Nate: that way to append works fine, thanks. Any chance you could make it so I can just select multiple files when initially loading to get the same result? The other thing I was thinking was for the bottom output, change the text for examining so the user knows what file is being examined. This way instead of saying "Yua is examining the file..." it would say "Examining Batman  Arkham City 02.17.2015 - 22.34.22.07.mp4." Most people wouldn't need this but for appending it would be nice to have a way of seeing the order the files are added together.

Mystery: Yeah I checked out the reasons behind the limitation a while ago and have been using Avidemux to merge the files together, but the process of merging before loading into Yua can take up to an hour with long enough runs.
I'm getting crashes all the time when I try to add a high amount of segments into Yua.

On my first try I added 1 by one and started trimming. Lost hours of progress I had with the edditing on the 52th video I added.

The second time, I tried to add the first segment and then append all others, but after a while loading the segments the program crashes. I also tested every segment individually and they all load properly when I put them alone or in a low quantity
the last two words are not promising for me to get the repro.

just shooting in the dark, what are your full system specs and os (also 32 or 64 bit)?
Edit history:
penta: 2015-03-04 02:58:45 am
Windows 8.1 64 bit
i7 4790k
Asus Z97M-Plus/BR
2x4 GB 1333 Corsair Vengeance
GeForce GTX 660
HDD WDC 500 GB 7200 RPM (with the video files)
SSD KINGSTON V300 120GB (running OS)
SSD OCZ Vertex 460 120GB (running Yua)

I tried something else, it was complicated. I edited every segment in VirtualDub to remove the loading screens (with smart rendering option using the same codec of the source file), got the files together in 3 groups also using Virtual Dub.

Got back to Yua, but it "eats" a few final frames of the video I edited. So, I put the source file of the video segment which was the last one in the group (1, 2 or 3) to replace the segment with deleted frames and then encoded with no problems. Now I'm waiting for the encode of the group 3 to end so I can join all the final encoded .mp4 files in Avidemux.
Edit history:
Judgy: 2015-03-04 05:18:12 am
Borderlands 2 Glitch Hunter/ router.
@ Penta , the crashing may be caused by destination file name length if it's anything like anri-chan, I used to have anri crash when I added a certain file "final_Mission_9;54.avi" when my other files "Mission_1.avi" , "mission_2.avi" etc etc worked fine the difference was that the destination string entered into anri-chan for that file was too long.

E.G :
"F:/fraps/Recordings/Rainbow Six Vegas 2/final_Mission_9;54.avi"
compared to
"F:/fraps/Recordings/Rainbow Six Vegas 2/Mission2_9;51.avi

This would cause anri to not be able to open that file and I would have to start again. could be that while appending it cannot open a file destination string over a certain length and goes crazy.

also check for unusual characters allowed when naming files but might cause confusion this includes -->  - = _ + [ ] { } ; ' @ # ~ , . ! £ $ % ^ & ( ) ¬ `

#LongShot

EDIT: can you open the file that crashed normally on its own?
My segments are all named like sg001, sg002.......sg050, sg051. Could that be the problem?
Edit history:
Judgy: 2015-03-04 05:22:12 am
Borderlands 2 Glitch Hunter/ router.
i wouldn't think so .... seeing as they are all the same length (as are their file destinations) I'm gunna fan boy and claim its 8.1's fault Tongue

Unless your maxing out your physical memory allocation but i doubt it with 8GB
Edit history:
penta: 2015-03-04 05:24:28 am
Funny that I used to encode much longer videos in Yua with no issues, I guess it's something related to the amount or size of the segments

I tried to append 50 segments = crash
40 = crash
35 = crash

Then i went to 25 and it worked, and I kept this way
Borderlands 2 Glitch Hunter/ router.
is the 52nd segment a longer segment than those before it?
Edit history:
penta: 2015-03-04 05:28:10 am
51 is shorter, but the 50th is much longer

I'm almost sure that it's not related to a specifc segment because the crash happens with any sample of segments, if the sample goes past a certain number
Borderlands 2 Glitch Hunter/ router.
hmmm no idea then if it was a particular file it would make sense, hopefully Nate will provide something useful. Tongue
Quote from penta:
Windows

ok yua may be running out of ram because it's a 32-bit program even under windows 64-bit. it can use up to about 3 gigabytes of ram. if you open task manager and then open all 52 or whatever segments then you can watch the memory usage of the program go up. if it crashes around the 3 gb mark then you will know what the problem is. at some point i will need to make a win64 version of yua (which could use all your ram) but i'm a little surprised to be honest because i didn't remember appending using that much ram ... yua doesn't store a lot of info about each segment. and it can't be the seeking indices because then opening the whole thing pre-appended to a single file would cause the crash. maybe the per-segment data structures are using more ram than i remember. anyway if you still have the segments then go ahead and pop them into yua and watch the ram usage when it crashes and let me know. thanks.
I made 2 tries on that, in the first one I had it to crash with 52 segments and ~21xx ram and in the second with 55 segments and 2250 usage. The first crash was Runtime error and then the windows message, the second one was directly the windows message "yua stopped working"

Attachment:
hmmm. not the clear indication i was looking for. can you tell me the information about these segments (codecs, dimensions, etc) so i can look at trying to reproduce sometime? thanks.

also: rereleased yua for os x built on qt 5.4.1 this time which fixes the drag and drop to open bug under 10.9+. download link is the same.
Edit history:
penta: 2015-03-09 07:05:10 pm
penta: 2015-03-09 07:02:34 pm
I believe this one has the biggest file size, the smallest one is about 200MB

If you need to know all the sizes I can share with you in PM.

Attachment:
I got progressive audio desync in a video I just encoded with Yua 7. I had recorded a 30 fps PC game in 60 fps with ShadowPlay, so I figured selecting F2 would be sensible. But the audio came out about a second ahead of the video by the end of the 21 minute video.

It turns out ShadowPlay has the option to record at 30 fps, so I'll use that in the future, but I though you'd want to know that F2 might be problematic for PC recordings.
would it be possible for you to toss me the mq or lq that's exhibiting it?
Edit history:
NMS: 2015-03-18 01:57:36 am
NMS: 2015-03-17 11:37:25 pm
Here you go. I had only done XQ, but I just did MQ and the result was similar. It's a bit hard to judge, but if you listen for weapon fire during the final battle, starting around 19:40 or the gating out sound around 20:34, you can see it's a little over a second ahead. There's no noticeable desync in the original file.

Edit: same result with Yua 8.

Attachment:
@nate: The output filename form does not accept parentheses. Is this on all platforms? Did you do that on purpose or is it a Qt5 thing?
i locked it to characters that are acceptable in sdanames (what comes after ? in the demo.pl link). regex:
Code:
[\w_\- ]+
HELLO!
So my Avermedia Game Capture HD 2 crashed and ate a run.  Defeats the purpose of having external recording to be easy and reliable, so I replaced it this week with an XCAPTURE Mini.

I beat the run the Avermedia ate, and went to encode it.  The XCapture Mini puts the recording in pieces, so I appended them all in, and the recording had some audio desync in the part of the video that came from the first piece of the recording.

I checked the individual pieces: no desync. I then joined the pieces together with ffmpeg.  No desync.  I then put that ffmpeg joined copy into Yua and tried to trim and encode my run with that.  Now the entire run got desynced.

I tried making a short test, appending the first two pieces and making an encode that crosses the piece boundary... no desync.

I'm at a loss here.