I'm having an issue where I can't move my encoded videos forward or back on any video player. This doesn't seem to be a problem once they're on YouTube, though, where I can skip things just fine.
I made a video showing how I encode things my own way. Here it is: https://www.youtube.com/watch?v=ht6dsX2buLM (I edited out the parts where the progress bars are moving just to speed things up)
The issue I'm talking about happens at around 6:00. I can move forward/back if I use convertavitomp4, as shown in 7:20, but it doesn't work if I use mkvtoolnix.
Can someone point out what I'm doing wrong, and how to fix this issue? It's just that I like being able to play my videos properly from my computer too.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Maybe it's the result of LZO. Gamer Maiden Sonia, try GZIP or a lossy codec.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I have experienced a few video players that just can't deal with specific codecs and thus fail to rewind properly. Usually VLC Player is the popular choice that works with a lot of video files.
So if you change the codec and it still doesn't work, try testing other popular video players I guess.
Or read the post below.
grassini wrote:
people edit their comments with more info,
You replied after the info was already added.
If the info was added afterwards, then there would be the
Last edited by <name> on <date>; edited 1 time in total
annotation under the reply.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
VLC has a history of multitudes of issues with playback. Here is the recommended playback guide for Windows users, which essentially installs and configures MPC-HC with LAV Video Decoder and madVR: http://tasvideos.org/forum/viewtopic.php?t=15223
An alternative with good playback technology is mpv, but that requires much more setup as its UI is confusing for most users, plus it requires command line stuff.
I'm sorry for the late answer, I was experimenting with things.
@feos
Tried GZIP. It .avi dumped fine (a bit slowly though), but when I tried to encode with vdub, it gave me this error:
@Lex
I must be blind, but where is this "force keyframes every" option? I don't see it anywhere.
I also tried your guide on the other thread. Did everything step by step but it still didn't solve the issue.
__________________
Anyway, seems like I found a solution to my problem. I used the x264 codec recommended by Spikestuff instead of camstudio, and now the final video playbacks perfectly.
I left the configurations window for the .avi dump like this:
Then I used the same configurations to encode with virtualdub. Except with Placebo as preset instead of Ultrafast. It takes forever to encode, but the final .avi size gets really small so it's worthy it.
I guess it's time I ditch my old camstudio codec and use the x264 from now on since it's working much better for my needs.
Have you tested it with and without Zero Latency setting? Afaik it reduces the compression strength in favor for speed, although if you dump too much data per second your storage device (e.g. HDD) might not be able to keep up. Might not be an issue today though.
Gamer Maiden Sonia wrote:
Then I used the same configurations to encode with virtualdub. Except with Placebo as preset instead of Ultrafast. It takes forever to encode, but the final .avi size gets really small so it's worthy it.
When encoding with VirtualDub and x264vfw you probably need to check that "VirtualDub Hack" checkbox. Also, if all you do is upload videos to YT (instead of also storing them), the whole process might be faster to reduce compressing strength if you have a fast internet upload connection.
EDIT: Also, always use the "Fast Recompress" option in VirtualDub's "Video" menu unless you use VirtualDub filters.
omg! So that was the issue! I checked that box and put 15 for keyframes and now the video playbacks correctly. ^^ I would never have guessed that on my own.
creaothceann wrote:
Have you tested it with and without Zero Latency setting? Afaik it reduces the compression strength in favor for speed, although if you dump too much data per second your storage device (e.g. HDD) might not be able to keep up. Might not be an issue today though.
I've tested without Zero latency and it apparently doesn't dump accurately. For example, on Double Dragon (J), the title screen saying "DOUBLE DRAGON" shows up at frame 9. If I dump with zero latency, the video will also show it at frame 9, but without it, the title screen shows up at frame 15. So there's this weird 6 frames delay for some reason. It's better to leave it checked.
creaothceann wrote:
When encoding with VirtualDub and x264vfw you probably need to check that "VirtualDub Hack" checkbox. Also, if all you do is upload videos to YT (instead of also storing them), the whole process might be faster to reduce compressing strength if you have a fast internet upload connection.
Can you tell me more about this VirtualDub hack? I didn't check it because I don't know what it does exactly. I hovered my cursor over it and the explanation didn't make much sense to me either.
creaothceann wrote:
EDIT: Also, always use the "Fast Recompress" option in VirtualDub's "Video" menu unless you use VirtualDub filters.
I use the resize filter to make my videos go full HD though, so I guess I can't use this fast recompress option.
Aktan wrote:
I think you should try Lagarith Lossless Codec as x264 is lossy (unless you encode to lossless RGB mode which is really not supported well).
I used the "single pass - lossless" option plus "accept only RGB" and the video looked lossless to me. I put it to play then took a snapshot of it and zoomed in to see if there were artifacts/blurriness or the like, but everything was clean/pixel perfect, exactly like how it shows on an emulator.
I've used Lagarith before but it was dumping rather awkwardly. Some frames were not being displayed correctly. It's been a couple years though so things might have changed now. But now that the camstudio playback problem was fixed, I guess I can go back to using it now.
_____________________________________
Anyway, if I decide to go back to the x264 codec for whatever reason, I was wondering about something. I see there's a commandline window on x264 (as it's shown on the bottom of the second pic of my second post), but I'm bad with this stuff. Can I do what I do on virtualdub through that commandline window alone? I only really do two things on vdub. First I resize to full HD like this:
Then I fix the framerate like this:
fceux dumps at a weird 60.100 fps for some reason. If I don't fix it, then the audio will be out of sync and YouTube automatically rejects the video file because it doesn't know how to work with decimal values.
So... I was wondering: If possible, what argument values I'd need to write in order to resize to 5x and fix the framerate at the same time?
it'd probably make the .avi dumping process slower, but maybe it'd be worthy it if it means I'd not need to mess around with virtualdub anymore.
FCEUX dumps at the correct real NES framerate (I think). YouTube should have no problems with it honestly, if it does, something else is wrong. We all use something called AviSynth to do what you do in VDub, then use the command line x264 which is updated and has (a LOT) more options. Honestly H.264 in AVI is an hack and shouldn't be used unless B-Frames are turned off, which would be true if you are using lossless mode.
Edit: My guess is YouTube doesn't like AVI too much. If you encode to MKV, it should support the weird FPS better.
When encoding with VirtualDub and x264vfw you probably need to check that "VirtualDub Hack" checkbox. Also, if all you do is upload videos to YT (instead of also storing them), the whole process might be faster to reduce compressing strength if you have a fast internet upload connection.
Can you tell me more about this VirtualDub hack? I didn't check it because I don't know what it does exactly. I hovered my cursor over it and the explanation didn't make much sense to me either.
I don't know much about it, something to do with using VirtualDub + x264 + AVI files. I just have it enabled when encoding via VirtualDub, and disabled when not.
Gamer Maiden Sonia wrote:
creaothceann wrote:
EDIT: Also, always use the "Fast Recompress" option in VirtualDub's "Video" menu unless you use VirtualDub filters.
I use the resize filter to make my videos go full HD though, so I guess I can't use this fast recompress option.
It means that VirtualDub doesn't decode the input video stream but just passes it along to the selected encoder. VirtualDub operates only in RGB colorspace, so if you have a YUV/YV12 source it'd do the conversion which is inherently lossy and takes some CPU processing. With an RGB source there's no quality loss but you'd waste some time routing the data through VirtualDub's processing code.
These days I do all my editing in Avisynth and use VirtualDub only for encoding (if at all), so I just leave that setting on "Fast Recompress". VirtualDubMod allows me to permanently save that setting.
Gamer Maiden Sonia wrote:
Anyway, if I decide to go back to the x264 codec for whatever reason, I was wondering about something. I see there's a commandline window on x264 (as it's shown on the bottom of the second pic of my second post), but I'm bad with this stuff. Can I do what I do on virtualdub through that commandline window alone? I only really do two things on vdub. First I resize to full HD like this:
<img>http://i.imgur.com/rcRMeIN.png</img>
Then I fix the framerate like this:
<img>http://i.imgur.com/jDDcF8w.png</img>
fceux dumps at a weird 60.100 fps for some reason. If I don't fix it, then the audio will be out of sync and YouTube automatically rejects the video file because it doesn't know how to work with decimal values.
So... I was wondering: If possible, what argument values I'd need to write in order to resize to 5x and fix the framerate at the same time?
it'd probably make the .avi dumping process slower, but maybe it'd be worthy it if it means I'd not need to mess around with virtualdub anymore.
x264 is a command-line program: you open a command-line window (e.g. cmd.exe) and type e.g.
x264 --help
to get a bit of help text (there's other options that show more), and e.g.
x264 --crf 24 --preset fast input.avi -o output.mkv
to encode input.avi to output.mkv using Constant Rate Factor 24 at "fast" speed.
Since I'm using Avisynth I just write a simple text file like this:
Language: Avisynth
AVISource("input.avi")
i = 5
PointResize(Width * i, Height * i)
AssumeSampleRate(round(60.0 * FrameRateDenominator / FrameRateNumerator * AudioRate))
AssumeFPS(60)
Result: http://i.imgur.com/Z8dxpXb.png
This slows down the video to 60fps and changes the audio sample frequency accordingly so that both are in sync. Youtube doesn't support >60fps, so it would drop frames until it's <= 60.
(Normal NES, SNES, etc. video is faster than the standard NTSC rate (60.0/1.001 Hz) because they skip displaying one scanline to get progressive instead of interlaced video. Less lines == faster frame rate.)
This text file is saved e.g. as "00.avs" and encoded with VirtualDub + x264vfw (VirtualDub understands Avisynth scripts). I also use a LameMP3 plugin to compress the audio down to 192 kbits/s, because uploading uncompressed audio is just a waste of time imo.
(Note that you can also encode Avisynth scripts using the x264 command-line program, but then you'd have to compress the audio with other tools.)
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
creaothceann wrote:
Gamer Maiden Sonia wrote:
creaothceann wrote:
When encoding with VirtualDub and x264vfw you probably need to check that "VirtualDub Hack" checkbox. Also, if all you do is upload videos to YT (instead of also storing them), the whole process might be faster to reduce compressing strength if you have a fast internet upload connection.
Can you tell me more about this VirtualDub hack? I didn't check it because I don't know what it does exactly. I hovered my cursor over it and the explanation didn't make much sense to me either.
I don't know much about it, something to do with using VirtualDub + x264 + AVI files. I just have it enabled when encoding via VirtualDub, and disabled when not.
That's because AVI isn't meant to contain video encoded to x264. It's outside of the AVI spec and a horrible practice, you're asking for trouble when you do this, like REALLY asking for trouble.
Also, AVI is bloody ancient, use a better container like mp4 or matroska (mkv), for which x264 encoded video will be living very happily in.
That's because AVI isn't meant to contain video encoded to x264. It's outside of the AVI spec and a horrible practice, you're asking for trouble when you do this, like REALLY asking for trouble.
Also, AVI is bloody ancient, use a better container like mp4 or matroska (mkv), for which x264 encoded video will be living very happily in.
Lossless AVI dump -> VirtualDub -> x264vfw (zero latency checked or it desyncs) -> youtube. This has been working for me for years perfectly.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
feos wrote:
Warepire wrote:
That's because AVI isn't meant to contain video encoded to x264. It's outside of the AVI spec and a horrible practice, you're asking for trouble when you do this, like REALLY asking for trouble.
Also, AVI is bloody ancient, use a better container like mp4 or matroska (mkv), for which x264 encoded video will be living very happily in.
Lossless AVI dump -> VirtualDub -> x264vfw (zero latency checked or it desyncs) -> youtube. This has been working for me for years perfectly.
And YT supporting it is then part of the problem as to why people do this.
I agree with Warepire. It's not a good idea to put H.264 in AVI as AVI does not support B-Frames natively. Only time where I would think it is somewhat okay is when you are encoding to lossless H.264 where B-Frames don't exist. It work, doesn't mean much as YT probably just hacked in the support (or FFMPEG).
Honestly H.264 in AVI is an hack and shouldn't be used unless B-Frames are turned off, which would be true if you are using lossless mode.
Warepire wrote:
That's because AVI isn't meant to contain video encoded to x264.
If I understand correctly, it's not a good idea to choose either then?
I know the x264 codec has 7 VFW FourCC options:
H264
h264
X264
x264
AVC1
avc1
VSSH
If I can't pick H264 nor x264, what should I pick then?
Honestly H.264 in AVI is an hack and shouldn't be used unless B-Frames are turned off, which would be true if you are using lossless mode.
Warepire wrote:
That's because AVI isn't meant to contain video encoded to x264.
If I understand correctly, it's not a good idea to choose either then?
I know the x264 codec has 7 VFW FourCC options:
H264
h264
X264
x264
AVC1
avc1
VSSH
If I can't pick H264 nor x264, what should I pick then?
The fourcc used isn't the problem. AVI cannot properly support mpeg4 part 10 aka h.264 aka AVC aka whatever you want to call it, regardless of fourcc labeling. You should not use that container to store that format.
Then I guess I will just keep using my old method, as seen on the OP's video. (Dump with camstudio losseless codec -> vdub -> MKVToolNix). Except with 1 keyframe every 60 frames so it will play properly on any video player.
I've tried it with quite a few videos so far and it's working perfectly for me.
@Lex
I must be blind, but where is this "force keyframes every" option? I don't see it anywhere.
I also tried your guide on the other thread. Did everything step by step but it still didn't solve the issue.
__________________
Anyway, seems like I found a solution to my problem. I used the x264 codec recommended by Spikestuff instead of camstudio, and now the final video playbacks perfectly.
I left the configurations window for the .avi dump like this:
Then I used the same configurations to encode with virtualdub. Except with Placebo as preset instead of Ultrafast. It takes forever to encode, but the final .avi size gets really small so it's worthy it.
I guess it's time I ditch my old camstudio codec and use the x264 from now on since it's working much better for my needs.
Then I fix the framerate like this:
fceux dumps at a weird 60.100 fps for some reason. If I don't fix it, then the audio will be out of sync and YouTube automatically rejects the video file because it doesn't know how to work with decimal values.
So... I was wondering: If possible, what argument values I'd need to write in order to resize to 5x and fix the framerate at the same time?
it'd probably make the .avi dumping process slower, but maybe it'd be worthy it if it means I'd not need to mess around with virtualdub anymore.
