PDA

View Full Version : Can't Fast forward or rewind MKV - MPEG2 files



Pelican
January 16th, 2013, 09:11 PM
I can't fast forward or rewind MPEG2 TS files saved as MPEG2 - MKV files on my Samsung HT-C5500 home theatre system on any version after Version 637g. I get a message "not available" every time I try. On all versions up to and including 637g this feature worked OK. I have tried with both Windows 7 and Windows 8
Cheers Brian

Dan203
January 17th, 2013, 11:52 AM
Do your files have multiple audio streams? Yu may want to click the Options button in the save dialog and uncheck the "Allow multiple audio streams" option. Other then that I'm not sure what would effect this. We did upgrade FFmpeg somewhere along the line, which is what we use for MKV muxing, but I remember looking at the source code once because of a user complaining about another issue and nothing significant had really changed in the MKV muxer that should cause a problem like that.

Dan

Pelican
January 20th, 2013, 05:22 AM
Hi Dan
The files do not have multiple audio streams, audio stream is mpeg layer 2 256kbps 48000khz as recorded from Australian digital TV.
I tried unchecking "allow multiple audio streams" anyway but same result.
Cheers Brian

Dan203
January 20th, 2013, 06:25 PM
Are you sure older versions still work? And that this was not something caused by an update to the firmware in your TV?

Dan

Pelican
January 20th, 2013, 08:05 PM
Older versions definitely still work.
I am back to using version 637 now for that reason.
Cheers Brian

Dan203
January 20th, 2013, 08:13 PM
Do any other containers work? TS, MPG?

Dan

Pelican
January 21st, 2013, 07:10 AM
will check and let you know

Dan203
January 21st, 2013, 04:01 PM
OK just want to know if it's a MKV problem or a stream problem. There have been a LOT of changes since 637 so we need to narrow it down.

Dan

Pelican
January 21st, 2013, 09:21 PM
TS and MPG files are OK
H264 saved as MKV files don't work either.
Is there some other option in the settings I can try. eg something that is on by default in the later versions but off in 637 and previous. I've had a look but nothing jumps out at me.
Cheers Brian

Dan203
January 22nd, 2013, 01:52 AM
Maybe. There is an option in the hidden area that might have an effect. Hold Shift and click Tools->Options. Near the bottom of the list is one called "Leave SPS/PPS in Mp4/MKV H.264 header". (or something along those lines) Try turning it off and see if that helps at all.

If not then it's likely some change in FFMpeg. I sort of remember some other having a problem that I traced back to a flag being set incorrectly in FFMpeg. But I could have sworn I fixed that.

Dan

Pelican
January 22nd, 2013, 02:58 AM
Changing that setting from true to false had no effect on either MPEG2 - MKV or H264 - MKV files

Dan203
January 22nd, 2013, 03:03 AM
Yeah that setting only effects H.264 so if this applies to MPEG2 then it wouldn't have an effect. I'll double check the FFmpeg code and see if that setting I was referring to was actually fixed.

Dan

MrVideo
January 24th, 2013, 02:31 AM
MKV files that I download do not appear to allow using the FF or REW button on my Samsung BD player as well. But, two programs that I packaged with mkvmerge do allow FF and REW. They are H.264 x264 encodings, though I doubt that the video format has anything to do with it. When I get a chance, I'll repackage one of the files that doesn't work and see what happens.

Obviously a flag issue. Not an IDR frame issue either, as these x264 encodings do not have IDR frames.

MrVideo
January 24th, 2013, 03:17 AM
Interesting. It does have something to do with the x264 encoder's output. Just repackaging the offending video did not fix it. Using media info on the file, it was not encoded with x264. The encoder name, and the options, were not embedded into the video. So, I don't know what was used for it.

So, that leads me to believe that it is not a packaging issue, but an encoder issue.

Dan203
January 24th, 2013, 03:23 AM
The original poster claims to have a problem with both H.264 and MPEG-2 video. He also says older version of VRD work OK so I'm pretty sure that in his case it's something with the MKV mux itself.

Dan

MrVideo
January 24th, 2013, 04:12 AM
The same version of mkvmerge was used for the repackaging and well as packaging files that I encode with x264. Because the common item in the test was the mkvmerge program, with the same options, that leaves the video itself as the reason. The mkv file that was produced by another used a different h.264 encoder, but was wrapped by mkvmerge.

I do not have any MPEG-2 files wrapped within MKV. I do not encode MPEG-2 for archiving, wrapped with MKV. Any, and all, MPEG-2 files that I have are TS files. I suppose I could do a test MPEG-2 encode and wrap it with MKV, but I'm not sure what it will prove, since the encoder is different. Still, might be worth a try.

I could also try letting VRD encode a short piece of video to H.264 and manually wrap it with mkvmerge and see what happens. Same goes for MPEG-2, depending on the results of the H.264 test.

Dan203
January 24th, 2013, 02:23 PM
You know I just bought a new Samsung smart TV. I haven't tried playing any local videos through it though. How do you do it? Direct input via USB key/drive or via the network? If via the network do you have something special running on your PC to make it work? If I can reproduce the problem I might be able to fix it easier.

Dan

tonys
January 24th, 2013, 02:47 PM
I don't know about the Samsung range but on my Panasonic I sometimes have to try both network and USB to achieve playback. I record H.264 AC3 and H.264 AAC programs and use VRD to edit and put them into MKV files. Make sure you don't have header compression on because that will probably noy play back on your tv. MKV files with no header compression will usually playback fine on my Panasonic tv from my Synology NAS using DLNA.

I often have problems with MP4 format files downloaded from the internet and these will commonly only replay by copying them to a USB key and playing them from there.

Good luck!

MrVideo
January 24th, 2013, 03:25 PM
Samsung is not following spec, in that compressed headers are part of the spec. As pointed out, header compression can't be used. Right now I just put stuff on a 32 GB flash drive, which should be formated for NTFS, so that files > 2 GB can be played. Setting up a DLNA server would be another way to go. I just never bought the license for the software that I installed. And yes, you can put files on an external HDD and connect it by USB.

Floobydust
January 24th, 2013, 05:41 PM
You know I just bought a new Samsung smart TV. I haven't tried playing any local videos through it though. How do you do it? Direct input via USB key/drive or via the network? If via the network do you have something special running on your PC to make it work? If I can reproduce the problem I might be able to fix it easier.

Dan

You should be able to use an external HD with USB. Also you could try to setup a shared folder on your computer and have the TV try to find--if it is smart enough :rolleyes: or maybe you may have to point the TV to the shared folder.

Mike...

tonys
January 24th, 2013, 05:56 PM
Don't forget that Window 7 Media Player includes a DLNA server function as standard. Just add the folders containing your video - music - photo files to the Media Player libraries and it should work fine. I usually keep temporary stuff - things I only intend to watch once - on my PC and replay them from there. I only copy stuff to my Synology NAS if I am going to keep it long term.

Dan203
January 24th, 2013, 06:12 PM
I'll look into it and see if I can reproduce the problem.

Dan

Pelican
January 28th, 2013, 08:46 AM
Just to confuse the issue, my Samsung smart TV model 40C6900 (couple of years old) will indeed FF and RW the same MPEG-2 MKV files that the Samsung Blueray HT system won't.
To stream MKV files from the PC I just use Samsung Allshare software on the PC because WMP won't recognise MKV files as video files for streaming to the TV.
Either streaming from the PC or playing from the USB port, flash drive or portable HDD, produces the same result.
Cheers Brian

MrVideo
February 6th, 2013, 12:17 PM
I'll look into it and see if I can reproduce the problem.

Well I just finished doing an H.264 test and discovered that your option setting for MKV are incorrect. An H.264 encoded file from VRD, manually wrapped by me, fast forwards just fine with my Samsung BD player. But, taking the same TS file and letting CRD create the MKV file results in the file not playing at all. It actually starts and then quits playing the file, an indicaion of compressed headers. While the Samsung TV might play the file, the compressed headers are probably the reason for the TV not being able to fast forward thru the file.

Here is an example of the required option for mkvmerge:

mkvmerge --clusters-in-meta-seek --default-language eng -o H264-test.mkv --compression -1:none H264-test.ts

I suspect it is also why MPEG-2 files have the same result.

Dan203
February 6th, 2013, 02:22 PM
Can you try going to S+T>O and turning off the "Leave SPS/PPS in MP4/MKV H.264 frames" and then try again. Since your files are H.264 that could have an effect on your previous test.

MrVideo
February 6th, 2013, 03:28 PM
OK, here are the results, with a bonus test.

I had deleted the H.264 test file that I created, but I had a short file that I had VRD recode to H.264 from the 60 Mbps MPEG-2 4:2:2 source.

With the SPS/PPS setting changed, the video played. But, FF was "not available." I then took that MKV file and repackaged it with my script. Therefore, the only difference is that it was re-wrapped. The H.264 video was the same. The three FF speeds now worked.

So, VRD is still setting something wrong when wrapping the video.

The bonus test was that I took a 35 Mbps MPEG-2 sat feed video and had VRD MKV wrap it. I should probably have VRD recode to a lower bitrate. While the Samsung player did play it, the time readout on the player stayed at zero. The FF speeds were available, but using one caused the video to restart back at zero.

I personally never wrap MPEG-2 files with MKV. The reason is that I take the MPEG-2 videos and recode to H.264 @ 23.976, removing the 2:3 pulldown. Those are what I watch.

Dan203
February 6th, 2013, 03:34 PM
OK thanks. I will double check the FFmpeg code. I'm pretty sure I made a fix for a similar issue a while ago but maybe it never got added to our release code.

Dan203
February 6th, 2013, 04:23 PM
Can you do me a favor. Download this file...

http://www.videoredo.net/customerfile/avformat-53.zip

Go to your VideoReDo install folder, rename avformat-53.dll to avformat-53.hld, then copy this new build to that directory. Now try outputting a MKV again and see if it restores the FF functionality. I did make a fix for this but I don't think the updated build ever got put into the release chain. I want to make sure this fixes it and if it does I'll get it to DanR so he can include it in the next beta.

MrVideo
February 6th, 2013, 06:36 PM
Nope. Still not available. Recoded the MPEG-2 short video to H.264/MKV, using forced recode, 2 pass. Plays, but no FF.

Dan203
February 6th, 2013, 06:58 PM
Hmmm... So then it's not related to that other issue then.

Any chance you'd be willing to download a more recent build of FFmpeg and use it's CLI app to remux your file and see if it fixes the problem? That would tell me if upgrading our FFmpeg build would fix the issue or not.

MrVideo
February 6th, 2013, 07:11 PM
Supply the link of the ffmpeg build you want me to download and the CLI instructions to use. I'm not a heavy ffmpeg user.

Dan203
February 6th, 2013, 07:19 PM
I'm not really a big FFmpeg CLI user either so give me a little bit to figure out exactly how that's done and then I'll get you what you need.

Dan203
February 6th, 2013, 08:07 PM
OK here is a link to the build...

http://www.videoredo.net/customerfile/FFmpeg.zip

The syntax is simply...

ffmpeg.exe -i input.ts -vcodec copy -acodec copy output.mkv

MrVideo
February 7th, 2013, 04:56 AM
I'm assuming that you want me to drop the files into the VRD program directory. Doing that will result in some naming conflicts, as there is a avformat-53.dll already there and you've supplied a new avformat-54.dll.

I'll have to directly name the program in the VRD program area, as I already have a standalone ffmpeg that is in my execution path.

Dan203
February 7th, 2013, 11:57 AM
No don't put those in the VRD path. That is a standalone build of FFmpeg. I just want you to use it to remux a file to MKV, using the CLI, and then play that on your TV to see if it fixes the problem. You can put it where ever you want.

MrVideo
February 7th, 2013, 01:22 PM
Testing complete: Not Available

Aren't there any other options to pass to ffmpeg that will do the following: --clusters-in-meta-seek & --compression -1:none

Those are the options needed with mkvmerge to get it to work correctly. I do not know what ffmpeg has that are equal in function.

Dan203
February 7th, 2013, 02:47 PM
No there are no options like that. The FFmpeg API is very generic so that it can support a wide variety of codecs and containers. It doesn't really have a means for passing in specific options like that.

Sorry but there is really nothing I can do. We use FFmpeg for MKV muxing. I'm not familiar enough with the source or the MKV format to start hacking away at it myself to add features like this. I'll submit a request to the FFmpeg group to see if anyone else can do it, but they haven't been very responsive to my questions or requests in the past.

MrVideo
February 7th, 2013, 03:03 PM
So, that begs the question... why not switch to using mkvmerge? It is a standalone program, no DLLs required.

Dan203
February 7th, 2013, 03:25 PM
We might be able to do that in the future, but really the only reason we have MKV support at all is because we added FFmpeg to replace the broken Main Concept MP4 muxer we originally had and MKV was basically "free". I'm not sure this is a big enough issue to warrant development of a dedicated MKV muxer using a completely different API.

MrVideo
February 7th, 2013, 04:26 PM
Just grab the mkvmerge executable and place it in the VRD program directory and then within the code exec the external mkvmerge, passing along the necessary options. Within C/C++ code it is extremely easy to run an external program and monitor any return codes. No need to get the source, which I'm not sure the author makes available.

Dan203
February 7th, 2013, 04:59 PM
That's not how VRD works. If we're going to do it that way then the user might as well just output to ES and then call mkvmerge themselves. We need a realtime muxing option that outputs to the MKV file as it's being output by VRD. The only thing in VRD that works the way you describe is our DVD muxing and we hate it. Requires all sorts of extra code we have to maintain to keep it functional. The only way we're going to switch MKV muxers is if there is a way to tie it directly into VRD like it is now.

MrVideo
February 7th, 2013, 08:15 PM
Then I guess the only cure is to get ffmpeg "fixed."

BTW, no need to output to ES, as mkvmerge will take a TS file as input.

Pelican
February 9th, 2013, 12:34 AM
OK here is a link to the build...

http://www.videoredo.net/customerfile/FFmpeg.zip

The syntax is simply...

ffmpeg.exe -i input.ts -vcodec copy -acodec copy output.mkv

I thought I'd try this suggestion myself to see if it would work for me but everytime I run the script I get
"Decoder (codec dvb_teletext) not found for input stream #0:2" haven't got a clue what it means
Cheers Brian

Dan203
February 9th, 2013, 07:12 PM
Your files apparently have DVB teletext captions and apparently FFmpeg doesn't like them. You can tey removing the captions in VRD by saving to .mpg and then process that to MKV just to see if it makes a difference.

Pelican
February 10th, 2013, 05:46 PM
Tried as you suggested but FF and REW still "not available" with MKV MPEG-2 files on Samsung BD player.

Cheers Brian

Dan203
February 11th, 2013, 12:05 AM
Unfortunately this appears to be a limitation of the FFmpeg MKV muxer. Until they fix it, or we decide to use a different MKV API, there isn't anything I can do. Sorry.

Pelican
February 11th, 2013, 06:24 PM
Thanks for looking into it Dan.
Build 637 meets my needs OK so I'll keep using that for now.

Cheers Brian

Dan203
February 12th, 2013, 06:09 PM
Can you guys try playing this file and see if it allows FF/RW? I found one minor thing in the FFmpeg code I think might have an effect on this so I changed it back to match the older version. Let me know one way or the other.

www.videoredo.net/customerfile/ff_test.mkv

Pelican
February 14th, 2013, 02:30 AM
No go with the test file, FF and REW still "not available" on my Samsung BD player

Cheers Brian

Dan203
February 14th, 2013, 02:50 AM
Then I don't know what changed. That was the only bit of code that I could see in the FFmpeg MKV muxer that changed and looked like it might have an effect on that sort of thing. Although there are big chunks of the code that were completely rewritten so any one of those sections could also have an effect. Unfortunately I'm not an expert on the MKV format so I can't say for sure what would cause this.

Dan203
February 14th, 2013, 04:11 PM
Can you do me a favor and upload a short clip that does allow FF/RW so I can look at it and see if there is anything obviously different about it compared to ones created with the latest build?

http://www.videoredo.net/msgBoard/showthread.php?15807-How-to-Upload-Samples-to-VideoReDo-Customer-Support

Pelican
February 17th, 2013, 08:21 PM
Dan

File uploaded as requested name FFtest.mkv (approx 5 mins) to folder Pelican

Cheers Brian

Dan203
February 20th, 2013, 03:14 PM
Dove into the FFmpeg code and found a fix. Will be in next beta.

MrVideo
February 20th, 2013, 04:03 PM
In a nutshell, what was it? Want to make a test version available to make sure that it works before releasing it in a beta?

Dan203
February 20th, 2013, 07:19 PM
The old version of FFmpeg had two seek heads, both in slightly different places. For some reason they removed one of them in the later builds. Probably because it wasn't strictly needed for perfect compliance. Anyway I simply added back the second seek head, and then sent a sample file to Pelican, and he confirmed that FF was available on both his TV and BD player.

MrVideo
February 20th, 2013, 09:26 PM
Did you inform the ffmpeg mail list about this change and why it was needed? I haven't been paying close attention to the mail list.

Dan203
February 20th, 2013, 11:37 PM
No. Last time I informed them about a change I made to the MKV muxer they basically said the code is to the MKV spec and if a device/player interprets it wrong then that's their problem. They're not interested in compatibility, only the spec. Or at least the guy in charge of e MKV muxer anyway.

Pelican
February 25th, 2013, 05:26 AM
FF and REW on MPEG-2 MKV files now works perfectly with latest build (654d) on my Samsung BD player.
Thanks Dan for your tireless efforts in tracking this down.

Cheers Brian