FFMPEG created WTV files cannot be fast forwarded or fast rewound in Windows Media Center

[ramitb]

Summary of the bug: Any WTV file created by FFMPEG, they can be seeked directly in MCE but when one tries toe fast forward or rewind (using the FF and RW buttons on the remote or the console) it does not go beyond at best 1 FF or 1 RW.
i.e. WTV files recorded by MCE one can press the FF button upto 4 times to get 4x fast forward. Files created by FFMPEG sometimes get 1x FF and never go beyond 1x FF, it just returns to normal play.

This happens with any WTV file, so you can take any file you have in your archive and remux it to wtv and see the results.

something as simple as:
ffmpeg -i test.ts -c copy test.wtv

I'm not uploading a sample since it can be reproduced with any file remuxed to WTV.

[Carl Eugen Hoyos]

In any case, please provide the command line you used to produce a test-file together with complete, uncut console output.

[ramitb]

Sure:

This is just one file, I get the same result with any file.

ffmpeg -i "..\Himoe_USA_WRC-HD.ts" -c copy test.wtv

ffmpeg version N-48065-g6375318 Copyright (c) 2000-2012 the FFmpeg developers
  built on Dec 21 2012 09:06:30 with gcc 4.7.2 (GCC)
  configuration: --enable-static --arch=x86 --target-os=mingw32 --cross-prefix=/home/rdp/dev/ffmpeg-windows-build-helper
s/sandbox/mingw-w64-i686/bin/i686-w64-mingw32- --pkg-config=pkg-config --enable-gpl --enable-libx264 --enable-avisynth -
-enable-libxvid --enable-libmp3lame --enable-version3 --enable-zlib --enable-librtmp --enable-libvorbis --enable-libtheo
ra --enable-libspeex --enable-libopenjpeg --enable-gnutls --enable-libgsm --enable-libfreetype --enable-fontconfig --ena
ble-libass --enable-libutvideo --enable-libopus --disable-w32threads --enable-frei0r --enable-filter=frei0r --enable-lib
vo-aacenc --enable-bzlib --enable-libxavs --extra-cflags=-DPTW32_STATIC_LIB --enable-libopencore-amrnb --enable-libopenc
ore-amrwb --enable-libvo-amrwbenc --enable-libschroedinger --enable-libbluray --enable-libvpx --enable-runtime-cpudetect

  libavutil      52. 12.100 / 52. 12.100
  libavcodec     54. 81.100 / 54. 81.100
  libavformat    54. 49.102 / 54. 49.102
  libavdevice    54.  3.102 / 54.  3.102
  libavfilter     3. 29.100 /  3. 29.100
  libswscale      2.  1.103 /  2.  1.103
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  2.100 / 52.  2.100
Input #0, mpeg, from '..\Himoe_USA_WRC-HD.ts':
  Duration: 00:20:26.79, start: 0.200000, bitrate: 15313 kb/s
    Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn,
59.94 tbc
    Stream #0:1[0x80]: Audio: ac3, 48000 Hz, stereo, fltp, 96 kb/s (visual impaired)
File 'test.wtv' already exists. Overwrite ? [y/N] y
Output #0, wtv, to 'test.wtv':
  Metadata:
    encoder         : Lavf54.49.102
    Stream #0:0: Video: mpeg2video (mpg2 / 0x3267706D), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 29.97 fps, 10000k
 tbn, 29.97 tbc
    Stream #0:1: Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, stereo, 96 kb/s (visual impaired)
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame=36773 fps=417 q=-1.0 Lsize= 2278828kB time=00:20:26.99 bitrate=15214.6kbits/s
video:2253105kB audio:14377kB subtitle:0 global headers:0kB muxing overhead 0.500394%

[Carl Eugen Hoyos]

Does it only happen with -codec copy, or also if you re-encode?

[ramitb]

With re-coding also, if I use -vcodec mpeg2video -acodec copy, I get the same result.

(ffmpeg WTV for now only supports MPEG2, I've submitted a request to support h.264)

[Carl Eugen Hoyos]

Replying to ramitbhalla:

With re-coding also, if I use -vcodec mpeg2video -acodec copy, I get the same result.

What about -acodec mp2 or -acodec ac3 ?

(ffmpeg WTV for now only supports MPEG2, I've submitted a request to support h.264)

I was under the impression trac user ianken submitted the request...

[ramitb]

WTV support for H.264 -> Ticket #1945 (been marked as duplicate of #536)

Here is the output of recoding, still the same issue while FF / RW:

ffmpeg -i "..\Himoe_USA_WRC-HD.ts" -vcodec mpeg2video -qscale 2 -acodec ac3 -ab 384k test.wtv

ffmpeg version N-48065-g6375318 Copyright (c) 2000-2012 the FFmpeg developers
  built on Dec 21 2012 09:06:30 with gcc 4.7.2 (GCC)
  configuration: --enable-static --arch=x86 --target-os=mingw32 --cross-prefix=/home/rdp/dev/ffmpeg-windows-build-helper
s/sandbox/mingw-w64-i686/bin/i686-w64-mingw32- --pkg-config=pkg-config --enable-gpl --enable-libx264 --enable-avisynth -
-enable-libxvid --enable-libmp3lame --enable-version3 --enable-zlib --enable-librtmp --enable-libvorbis --enable-libtheo
ra --enable-libspeex --enable-libopenjpeg --enable-gnutls --enable-libgsm --enable-libfreetype --enable-fontconfig --ena
ble-libass --enable-libutvideo --enable-libopus --disable-w32threads --enable-frei0r --enable-filter=frei0r --enable-lib
vo-aacenc --enable-bzlib --enable-libxavs --extra-cflags=-DPTW32_STATIC_LIB --enable-libopencore-amrnb --enable-libopenc
ore-amrwb --enable-libvo-amrwbenc --enable-libschroedinger --enable-libbluray --enable-libvpx --enable-runtime-cpudetect

  libavutil      52. 12.100 / 52. 12.100
  libavcodec     54. 81.100 / 54. 81.100
  libavformat    54. 49.102 / 54. 49.102
  libavdevice    54.  3.102 / 54.  3.102
  libavfilter     3. 29.100 /  3. 29.100
  libswscale      2.  1.103 /  2.  1.103
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  2.100 / 52.  2.100
Input #0, mpeg, from '..\Himoe_USA_WRC-HD.ts':
  Duration: 00:20:26.79, start: 0.200000, bitrate: 15313 kb/s
    Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn,
59.94 tbc
    Stream #0:1[0x80]: Audio: ac3, 48000 Hz, stereo, fltp, 96 kb/s (visual impaired)
Please use -q:a or -q:v, -qscale is ambiguous
File 'test.wtv' already exists. Overwrite ? [y/N] y
Output #0, wtv, to 'test.wtv':
  Metadata:
    encoder         : Lavf54.49.102
    Stream #0:0: Video: mpeg2video (mpg2 / 0x3267706D), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 10000k
tbn, 29.97 tbc
    Stream #0:1: Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, stereo, fltp, 384 kb/s (visual impaired)
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video -> mpeg2video)
  Stream #0:1 -> #0:1 (ac3 -> ac3)
Press [q] to stop, [?] for help
incomplete frame 42 q=2.0 size= 3780118kB time=00:20:26.77 bitrate=25242.3kbits/s dup=1 drop=0
frame=36774 fps= 42 q=2.0 Lsize= 3784576kB time=00:20:26.99 bitrate=25267.7kbits/s dup=1 drop=0    =0
video:3714268kB audio:57507kB subtitle:0 global headers:0kB muxing overhead 0.339377%

[ramitb]

Wonder if anyone's noticed the votes this issue is getting ;)

[ramitb]

Peter Ross any thoughts on this one? I know you had fixed this some time ago in Dec, FF is partly working now. Any idea why not completely?

[Scott Malinowski]

I have this problem too. I would love to have it resolved. Would gladly donate to the cause.

[pross]

The fast forward/rewind functionality in Windows Media Center is related to 'dvr_ms_vid_frame_rep_data' and/or 'DSATTRIB_PicSampleSeq' .wtv timeline chunks. These chunks have not been reverse engineered.

[ramitb]

Peter any chance you'll be looking into this?

[audinutt]

Would love to see this worked out, will patiently wait...

[mschmid4]

Adding my vote for this. Glad to see the issue has been isolated, a fix would be extremely helpful. Wife loves her fast forward in MCE!

[Ron]

Added my vote for this too.

[mae2759]

Me too. Please look at this!!!

You can't say no to this sad puppy...

"Pwwwwwweaseeeee? It's 'ruff' to fast forward!"

[BobbyBigBuns]

Thanks for looking into this. Please fix as soon as possible.

[Clément Bœsch]

Replying to mae2759:

Me too. Please look at this!!!

You can't say no to this sad puppy...

[...]

"Pwwwwwweaseeeee? It's 'ruff' to fast forward!"

The FFmpeg project is not into social coding. If you want a feature desperately, you can propose a bounty. Also note that a lot of FFmpeg developers do not have access to a Windows machine.

[compn]

if someone can get the spec from microsoft (or find some other open source code that details this) so we can implement the metadata chunks, that would speed this feature up considerably.