Jump to content


Photo

MPEG2 transcoding instead of direct play (AVCHD is OK)


Best Answer unisoft , 04 March 2019 - 08:06 AM

So they are originally mpg files? Whatever they were originally, that is how i would keep them.

 

RIGHT got to the bottom of it all.

 

Basically FFMPEG is being STRICT on headers. If it IS a ".TS" file extension then it expects the file to conform 100% to TRANSPORT STREAM header rules.

 

VideoRedo was likely doing a MPEG PROGRAM STREAM when .mpg was corrected originally.

 

I changed to Quicksteam fix in VideoREDO to .TS TRANSPORT STREAM and the resulting file (which is bigger) then plays fine on ROKU as a ".TS" file extension.

 

CONCLUSION: The media players auto compensated transparently for MPG or TS on playback regardless of what the file actually was. FFMPEG is being strict when consulting headers hence failure as the files not Transport headers. I think a note should go in the WIKI under file formats to state FFMPEG is strict on file type under extensions like .TS?

 

Happy now. At least I know the reason and thanks @speechles too. 

Go to the full post


  • Please log in to reply
27 replies to this topic

#1 unisoft OFFLINE  

unisoft

    Advanced Member

  • Members
  • 225 posts
  • Local time: 11:24 AM

Posted 02 March 2019 - 08:43 AM

Hello

 

I have the ROKU Streaming Stick on v9.0 (latest) and on latest Emby version and Synology NAS on Latest released Emby 4.0.0.2.

 

Two issues - both are MPEG2 playback of videos.

 

Issue 1: Live TV playback of MPEG2 channels in SD:

 

MPEG4 HD Live TV is fine and no transcode.

 

MPEG2 SD channels transcode despite the ROKU stick supporting MPEG2 now.

 

I use HD Homerun quad tuner on gigabit network (not ISP dumb router or cheap switch).

 

Here is the paste of the log from server - it complains about Container not supported?

 

2019-03-02 11:31:20.080 Info HttpServer: HTTP GET http://192.168.1.35:...nerNotSupported. Host=192.168.1.35:8096, User-Agent=Roku/DVP-9.0 (509.00E04142A), Accept=*/*, Accept-Encoding=deflate, gzip
2019-03-02 11:31:20.083 Info HttpServer: HTTP Response 200 to 192.168.1.88. Time: 3ms. http://192.168.1.35:...nerNotSupported

 

Issue 2: Playback of MPEG2 file content (SD) .TS:

 

Also, MPEG2 .TS files sit at "Retrieving" progress bar. I'm sure this played fine in previous versions of Emby and they play fine on Samsung and LG apps. I don't get what "No direct play profiles found for Path" means in log below as set to "AUTO" for playback.

 

here is log of that

2019-03-02 10:59:49.356 Info HttpServer: HTTP Response 204 to 192.168.1.88. Time: 16ms. http://192.168.1.35:...pabilities/Full
2019-03-02 10:59:49.372 Info HttpServer: HTTP POST http://192.168.1.35:...eticks=00000000. UserAgent: Roku/DVP-9.0 (509.00E04142A)
2019-03-02 10:59:49.596 Info App: User policy for LAN. EnablePlaybackRemuxing: True EnableVideoPlaybackTranscoding: True EnableAudioPlaybackTranscoding: True
2019-03-02 10:59:49.614 Info App: Profile: Roku SG, Path: /volume1/Multimedia/TV Archive/Drama/Tales Of The Unexpected/Season 1/s01e01 Tales Of The Unexpected - Man From The South.ts, isEligibleForDirectPlay: True, isEligibleForDirectStream: True
2019-03-02 10:59:49.632 Info App: Profile: Roku SG, No direct play profiles found for Path: /volume1/Multimedia/TV Archive/Drama/Tales Of The Unexpected/Season 1/s01e01 Tales Of The Unexpected - Man From The South.ts
2019-03-02 10:59:49.664 Info App: RemoteClientBitrateLimit: 12000000, RemoteIp: 192.168.1.88, IsInLocalNetwork: True
2019-03-02 10:59:49.664 Info App: Profile: Roku SG, Path: /volume1/Multimedia/TV Archive/Drama/Tales Of The Unexpected/Season 1/s01e01 Tales Of The Unexpected - Man From The South.ts, isEligibleForDirectPlay: True, isEligibleForDirectStream: True
2019-03-02 10:59:49.664 Info App: Profile: Roku SG, No direct play profiles found for Path: /volume1/Multimedia/TV Archive/Drama/Tales Of The Unexpected/Season 1/s01e01 Tales Of The Unexpected - Man From The South.ts
2019-03-02 10:59:49.664 Info App: RemoteClientBitrateLimit: 12000000, RemoteIp: 192.168.1.88, IsInLocalNetwork: True
2019-03-02 10:59:49.664 Info App: Profile: Roku SG, Path: /volume1/Multimedia/TV Archive/Drama/Tales Of The Unexpected/Season 1/s01e01 Tales Of The Unexpected - Man From The South.ts, isEligibleForDirectPlay: True, isEligibleForDirectStream: True
2019-03-02 10:59:49.664 Info App: Profile: Roku SG, No direct play profiles found for Path: /volume1/Multimedia/TV Archive/Drama/Tales Of The Unexpected/Season 1/s01e01 Tales Of The Unexpected - Man From The South.ts
2019-03-02 10:59:49.688 Info App: RemoteClientBitrateLimit: 12000000, RemoteIp: 192.168.1.88, IsInLocalNetwork: True
2019-03-02 10:59:49.716 Info HttpServer: HTTP Response 200 to 192.168.1.88. Time: 344ms. http://192.168.1.35:...eticks=00000000
2019-03-02 10:59:49.759 Info HttpServer: HTTP GET http://192.168.1.35:...Enhancers=false. UserAgent: Roku/DVP-9.0 (509.00E04142A)
2019-03-02 10:59:49.769 Info HttpServer: HTTP Response 200 to 192.168.1.88. Time: 10ms. http://192.168.1.35:...Enhancers=false
2019-03-02 10:59:49.781 Info HttpServer: HTTP GET http://192.168.1.35:...fb06d801bfc914a. Connection=close, Host=192.168.1.35:8096, User-Agent=Roku/DVP-9.0 (509.00E04142A)
2019-03-02 10:59:49.782 Error HttpServer: Could not find handler for /emby/Videos/107439/index.bif
2019-03-02 10:59:49.789 Info HttpServer: HTTP GET http://192.168.1.35:...nerNotSupported. Host=192.168.1.35:8096, User-

 



#2 ebr OFFLINE  

ebr

    Chief Bottle Washer

  • Administrators
  • 44879 posts
  • Local time: 06:24 AM

Posted 02 March 2019 - 10:01 AM

Hi.  Please attach the ffmpeg log from that playback.

 

Thanks.



#3 unisoft OFFLINE  

unisoft

    Advanced Member

  • Members
  • 225 posts
  • Local time: 11:24 AM

Posted 02 March 2019 - 10:57 AM

Hi.  Please attach the ffmpeg log from that playback.

 

Thanks.

 

It created TWO logs for playback of the media MPEG2 SD file (these files ahve played for years on virtually any other player like Windows Media Center, LG and Samsung Emby app, Media Player, VLC, MAC Media apps).

 

I attach the text logs. They are MPEG2 720x576 PAL, Anamorphic flag for 16:9 on 4:3 content, and Dolby Digital (AC3) - (DVD source content).

 

thanks :)

Attached Files


Edited by unisoft, 02 March 2019 - 11:00 AM.


#4 speechles OFFLINE  

speechles

    Advanced Member

  • App Developer
  • 4467 posts
  • Local time: 03:24 AM

Posted 02 March 2019 - 11:51 AM

[mpegts @ 0xe89e40] Could not detect TS packet size, defaulting to non-FEC/DVHS
[mpegts @ 0xe89e40] PES packet size mismatch
    Last message repeated 495 times
[mpegts @ 0xe89e40] probed stream 0 failed
[mpegts @ 0xe89e40] nothing to probe for stream 1
[mpegts @ 0xe89e40] probed stream 1 failed
[mpegts @ 0xe89e40] probed stream 2 failed
[mpegts @ 0xe89e40] probed stream 3 failed

The Roku cannot direct play TS files and allow seeking. To give you the ability to seek TS streams we must transcode them. This should show as DirectStream in the Stats-for-Nerds of the app. DirectStream will copy both the video and audio stream. If the audio is not supported it will Remux. Remux is directly copied video stream and transcoded audio stream.

 

The reason your file does not play on Roku is because the header is corrupted. Ffmpeg cannot find streams inside the TS file to play. This causes ffmpeg to stall and hang. The Roku app will hang for a bit but should timeout and error eventually. When the Roku app errors it will tell the server to kill the stalled ffmpeg process.

 

Are you sure this file plays on other Emby apps?

 

You might be able to use MKVToolNix GUI (drag 'n drop) to convert the TS into MKV. The Roku will play MKV with MPEG2/AC3 directly no problem. If you can get the streams out of that TS which might be possible with MKVToolNix.


Edited by speechles, 02 March 2019 - 12:13 PM.


#5 unisoft OFFLINE  

unisoft

    Advanced Member

  • Members
  • 225 posts
  • Local time: 11:24 AM

Posted 02 March 2019 - 02:09 PM

[mpegts @ 0xe89e40] Could not detect TS packet size, defaulting to non-FEC/DVHS
[mpegts @ 0xe89e40] PES packet size mismatch
    Last message repeated 495 times
[mpegts @ 0xe89e40] probed stream 0 failed
[mpegts @ 0xe89e40] nothing to probe for stream 1
[mpegts @ 0xe89e40] probed stream 1 failed
[mpegts @ 0xe89e40] probed stream 2 failed
[mpegts @ 0xe89e40] probed stream 3 failed

The Roku cannot direct play TS files and allow seeking. To give you the ability to seek TS streams we must transcode them. This should show as DirectStream in the Stats-for-Nerds of the app. DirectStream will copy both the video and audio stream. If the audio is not supported it will Remux. Remux is directly copied video stream and transcoded audio stream.

 

The reason your file does not play on Roku is because the header is corrupted. Ffmpeg cannot find streams inside the TS file to play. This causes ffmpeg to stall and hang. The Roku app will hang for a bit but should timeout and error eventually. When the Roku app errors it will tell the server to kill the stalled ffmpeg process.

 

Are you sure this file plays on other Emby apps?

 

You might be able to use MKVToolNix GUI (drag 'n drop) to convert the TS into MKV. The Roku will play MKV with MPEG2/AC3 directly no problem. If you can get the streams out of that TS which might be possible with MKVToolNix.

 

 

Hi, yes I have around 1000 MPEG2 files at least and they all give them the same result BUT only on Roku. All other players and the LG App and Samsung Emby app play them fine (direct).



#6 speechles OFFLINE  

speechles

    Advanced Member

  • App Developer
  • 4467 posts
  • Local time: 03:24 AM

Posted 02 March 2019 - 03:16 PM

Any app that has to transcode these will run into the same problem. Are you using a custom ffmpeg? Is there something different about your OS install?

 

It is related to transcoding and being able to probe the file that causes Roku to fail. It isn't anything the Roku is doing or that we are doing in the Roku app. The Roku is the end device experiencing the issue but isn't the root cause. The cause is happening when the Roku tells the Emby server that it does not support the TS container. This involves ffmpeg and hls streaming. That means it is something larger causing your issue within ffmpeg or your files themselves.



#7 unisoft OFFLINE  

unisoft

    Advanced Member

  • Members
  • 225 posts
  • Local time: 11:24 AM

Posted 02 March 2019 - 03:58 PM

Any app that has to transcode these will run into the same problem. Are you using a custom ffmpeg? Is there something different about your OS install?

 

It is related to transcoding and being able to probe the file that causes Roku to fail. It isn't anything the Roku is doing or that we are doing in the Roku app. The Roku is the end device experiencing the issue but isn't the root cause. The cause is happening when the Roku tells the Emby server that it does not support the TS container. This involves ffmpeg and hls streaming. That means it is something larger causing your issue within ffmpeg or your files themselves.

 

Those videos have been ripped (sometimes recoded) from Windows 7, Windows 8.1 and Windows 10 (various versions) over the years using DVD Shrink (without re-encoding to extract the initial DVD with AnyDVD) and sometimes using paid for TPMGEnc editing products where some were recoded. They conform to UK PAL broadcast standards - in fact they are usually a copy from the DVD as coded. I've never had an issue in any player before.

 

If I rename them to ".mpg" they play direct fine on Roku Emby. In older versions of the ROKU OS, they were renamed to .TS as .TS is technically the right extension for MPEG2 and MPG is really meant for MPEG1. I'm sure I renamed them because it didn't like .mpg in the Emby Roku version at the time.

 

So if they are corrupt (and I haven't got 1000, I have 1000's), the question is why a simple extension rename makes them work fine again? The correct extension though is .TS - this should still work in Roku like all the other players (even Emby ones like LG and Samsung play them as .TS fine).

 

I can't use MKV as I reserve MKV for 24p files so that Media Browser 2.6.2 can switch to a different player based on file extension, so that 24hz switching happens on the computer graphics card that normally runs at PAL 50hz. At the moment I need to keep backwards compatibility with MB 2.6.2 as well. Again MB 2.6.2 doesn't have an issue with .TS or .mpg. It just plays them.


Edited by unisoft, 02 March 2019 - 04:07 PM.


#8 speechles OFFLINE  

speechles

    Advanced Member

  • App Developer
  • 4467 posts
  • Local time: 03:24 AM

Posted 02 March 2019 - 05:10 PM

I did not say your files were corrupt. I said that ffmpeg could not read the header which implies your ffmpeg is wrong or the files were.

 

When you change extension/container(by simply rename the extension) it changes how the app will see the header constructed. It isn't something you should do as most media players do not probe the file. They try to follow the rules the extension has told them to acquire the header. The header tells how to decompose the container so you can consume the streams inside.

 

The files are not corrupt. Ffmpeg merely acts like they are because it doesn't understand the header of the file because the extension was changed. The moment you change the extension back to what it really should be all the problems should disappear.

 

MB 2.6.2 doesn't have an issue with the files because it isn't server/client it is just server+client in one. In this way it can direct play the file and know the right extension even though you lie to it. This can work since Windows would be fixing the mistake.


Edited by speechles, 02 March 2019 - 05:19 PM.


#9 unisoft OFFLINE  

unisoft

    Advanced Member

  • Members
  • 225 posts
  • Local time: 11:24 AM

Posted 02 March 2019 - 06:59 PM

I did not say your files were corrupt. I said that ffmpeg could not read the header which implies your ffmpeg is wrong or the files were.

 

When you change extension/container(by simply rename the extension) it changes how the app will see the header constructed. It isn't something you should do as most media players do not probe the file. They try to follow the rules the extension has told them to acquire the header. The header tells how to decompose the container so you can consume the streams inside.

 

The files are not corrupt. Ffmpeg merely acts like they are because it doesn't understand the header of the file because the extension was changed. The moment you change the extension back to what it really should be all the problems should disappear.

 

MB 2.6.2 doesn't have an issue with the files because it isn't server/client it is just server+client in one. In this way it can direct play the file and know the right extension even though you lie to it. This can work since Windows would be fixing the mistake.

 

I'm not sure what you mean by FFMPEG could possibly be wrong. On my Synology it would have been installed by Emby 3.x then upgrade to v4.x? I haven't got any other aps installed other than Synology's OS and Emby.

 

Should they be renamed back to .mpg then from .TS (even though that's really intended for mp1)?

 

Versions found in Emby log file:

 

ffmpeg version 4.0.2-emby_2018_12_09-20181219T192320UTC Copyright © 2000-2018 the FFmpeg developers
built with gcc 7.3.0 (GCC)
configuration: --prefix=/var/packages/EmbyServer/target/ffmpeg --enable-cross-compile --cross-prefix=x86_64-syno-linux-gnu- --target-os=linux --disable-rpath --enable-pthreads --arch=x86_64 --enable-libzimg --enable-libmfx --enable-vaapi --enable-x86asm --enable-gpl --enable-shared --disable-static --disable-debug --disable-ffplay --disable-doc --disable-htmlpages --disable-manpages --disable-podpages --disable-txtpages --enable-gnutls --enable-libass --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libfreetype --enable-fontconfig --enable-gray --enable-libfribidi --enable-libvidstab --enable-libzvbi --disable-indev=sndio --disable-outdev=sndio --extra-version=20181219T192320UTC --extra-libs='-luuid -lstdc++'
libavutil      56. 14.100 / 56. 14.100
libavcodec     58. 18.100 / 58. 18.100
libavformat    58. 12.100 / 58. 12.100
libavdevice    58.  3.100 / 58.  3.100
libavfilter     7. 16.100 /  7. 16.100
libswscale      5.  1.100 /  5.  1.100
libswresample   3.  1.100 /  3.  1.100
libpostproc    55.  1.100 / 55.  1.100


Edited by unisoft, 02 March 2019 - 07:13 PM.


#10 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 129329 posts
  • Local time: 06:24 AM

Posted 02 March 2019 - 10:45 PM

Those example logs are not full transcodes anyway, the video is being stream copied into a new container.

 

Have you checked out our media conversion feature? It can help you pre-convert your files into more streaming friendly formats.



#11 unisoft OFFLINE  

unisoft

    Advanced Member

  • Members
  • 225 posts
  • Local time: 11:24 AM

Posted 03 March 2019 - 03:09 PM

Those example logs are not full transcodes anyway, the video is being stream copied into a new container.

 

Have you checked out our media conversion feature? It can help you pre-convert your files into more streaming friendly formats.

 

Thanks but have several TB of MPEG2. I have renamed using a utility all back to .MPG and they are playing fine now on Android, LG App, Samsung and Roku and of course MB 2.6.2 on Windows Media Center.

 

I renamed them originally because of issues, and I am sure it was the ROKU version at the time when the ROKU OS was 8.x (now 9.0.0). As I said technically MPEG2 is .TS not .mpg. MPEG2 is still the most widely used codec due to broadcast and DVD even though I know H264/H265 formats are more efficient. H265 isn't intended for interlaced SD formats though and MPEG2 is easier to edit with and do smart rendering without re-encoding and only at edit points.


Edited by unisoft, 03 March 2019 - 03:11 PM.


#12 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 129329 posts
  • Local time: 06:24 AM

Posted 03 March 2019 - 07:44 PM

So they are originally mpg files? Whatever they were originally, that is how i would keep them.



#13 unisoft OFFLINE  

unisoft

    Advanced Member

  • Members
  • 225 posts
  • Local time: 11:24 AM

Posted 04 March 2019 - 07:49 AM

So they are originally mpg files? Whatever they were originally, that is how i would keep them.

 

Sort of. I chose them to be that file extension originally, but natively they would have been MPEG2 rips using DVD Shrink without re-encode and AnyDVD of DVD VOB files (combined where multiple VOBS exist).

 

VideoREDO 4 (paid for commercial product) then does a "Quickstream" fix to correct any timing errors so the MPEG2 file is seek-able during FF and RW as often a RIP won't do this on its own.

 

The others that are a recode (because of edits) would have been done in a TMPGENC (paid for commerical) editing product that smart renders and re-codes where necessary to PAL standards for UK (720x576 25 frames interlaced usually)

 

Both products are proper commerical apps.


Edited by unisoft, 04 March 2019 - 07:52 AM.


#14 unisoft OFFLINE  

unisoft

    Advanced Member

  • Members
  • 225 posts
  • Local time: 11:24 AM

Posted 04 March 2019 - 08:06 AM   Best Answer

So they are originally mpg files? Whatever they were originally, that is how i would keep them.

 

RIGHT got to the bottom of it all.

 

Basically FFMPEG is being STRICT on headers. If it IS a ".TS" file extension then it expects the file to conform 100% to TRANSPORT STREAM header rules.

 

VideoRedo was likely doing a MPEG PROGRAM STREAM when .mpg was corrected originally.

 

I changed to Quicksteam fix in VideoREDO to .TS TRANSPORT STREAM and the resulting file (which is bigger) then plays fine on ROKU as a ".TS" file extension.

 

CONCLUSION: The media players auto compensated transparently for MPG or TS on playback regardless of what the file actually was. FFMPEG is being strict when consulting headers hence failure as the files not Transport headers. I think a note should go in the WIKI under file formats to state FFMPEG is strict on file type under extensions like .TS?

 

Happy now. At least I know the reason and thanks @speechles too. 


Edited by unisoft, 04 March 2019 - 08:07 AM.

  • ebr likes this

#15 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 129329 posts
  • Local time: 06:24 AM

Posted 04 March 2019 - 03:22 PM

Thanks for the feedback.



#16 Starlionblue OFFLINE  

Starlionblue

    Advanced Member

  • Members
  • 456 posts
  • Local time: 06:24 PM

Posted 08 May 2019 - 04:22 AM

So what can I do to make these files play direct? Use the media conversion feature on all of them?

 

(Bought a Roku last week.)


Edited by Starlionblue, 08 May 2019 - 04:22 AM.


#17 speechles OFFLINE  

speechles

    Advanced Member

  • App Developer
  • 4467 posts
  • Local time: 03:24 AM

Posted 08 May 2019 - 11:24 AM

So what can I do to make these files play direct? Use the media conversion feature on all of them?

 

(Bought a Roku last week.)

 

Get MKVToolNix GUI. Then drag and drop your files onto the right hand side of the GUI. In the bottom make sure all streams are checked to copy. Hit the "Start Remux" button. It should take a few seconds. As MKV these can play back just fine. It is only when these are TS in direct play that the Roku assumes these are live streams and does not allow seeking. It thinks this is linear TV and you just get a pause button. To allow seeking we must repackage these into HLS/m3u8 and create TS slices. HLS can seek. TS directly cannot. MKV can always seek. MKV is your best friend.


Edited by speechles, 08 May 2019 - 11:25 AM.

  • Starlionblue likes this

#18 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 129329 posts
  • Local time: 06:24 AM

Posted 08 May 2019 - 01:24 PM

Yes I would suggest using our media conversion feature.
  • Starlionblue likes this

#19 Starlionblue OFFLINE  

Starlionblue

    Advanced Member

  • Members
  • 456 posts
  • Local time: 06:24 PM

Posted 08 May 2019 - 06:36 PM

Thx for the replies.

 

I pointed the conversion features at a few files and it worked fine. Roku plays the converted files without transcoding.

 

Trying MKVToolNix GUI but it can only do one file at a time I think.

 

 I'll try to script with MKVMerge so I can do batches but I need coffee first. Any hints appreciated.  :)


Edited by Starlionblue, 08 May 2019 - 06:56 PM.


#20 Starlionblue OFFLINE  

Starlionblue

    Advanced Member

  • Members
  • 456 posts
  • Local time: 06:24 PM

Posted 08 May 2019 - 07:58 PM

Ha. After an hour of fiddling with command line MKVMerge without success I found the "Actions for all Tabs" menu in MKVToolNix.  :lol:






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users