WTV driving me nuts

I am currently fighting with the .wtv transcoding. I use a hd-pvr within WMC7 for all my tv recording (movies, series, etc) and it would be great to share them without having to convert them. They are h.264 wtv (audio depends on source channel but is either aac or ac3). I wrote a perl script as a layer between serviio and ffmpeg so I could modify various items that I cannot find a way to modify within serviio. For instance -r, for some reason I see really odd -r parameters like 59.37 and 63.27 and I assure you they generally record at 23.976 and are all 1080i cbr 10mbs. I used what serviio sent out to ffmpeg and played a couple and they were horrible, jerky and pretty much unplayable. Just overriding the -r to 23.976 made them pretty darn good... I also played with -bufsize and increased that and the resulting files play great , if I rename them to xxx.ts and move them to a usb drive and play them directly from the tv. When I uses serviio I get an "invalid file" error from my LG TV as well as the bravia and samsung tvs and blueray players, but they all play the files if I serve them from a usb drive as a .ts. I am thinking there is something odd here. I am doing most of the test with a nearby LG E322VL that is using the following profile

<Profile id="15" name="LG NetCast.TV" extendsProfileId="1">
<Detection>
<HttpHeaders>
<USER-AGENT>.*LGE_DLNA_SDK.*</USER-AGENT>
</HttpHeaders>
</Detection>
<Transcoding>
<Video targetContainer="mpegts" targetVCodec="mpeg2video" maxVBitrate="10000">
<Matches container="wtv" />
</Video>
</Transcoding>
</Profile>
As I said most of my media is h.264 5.1 ac3 or aac and this profile plays any of the .ts with those specs (usually 20mbs and 448k) as well as a dozen or so blue ray rips in .mkv form (main feature rips only) but the wtv is just not working.

The command line that I out put that creates files I can play on the tv (and this processed command line from serviio)

/usr/bin/ffmpegReal -i /mnt/RecordedTV/Tosh.0_CCHD_2011_03_15_21_57_00.wtv -y -threads 1 -vcodec mpeg2video -b 10000k -maxrate 10000k -r 23.976 -g 15 -acodec copy -map 0:1 -map 0:0 -sn -bufsize 65535k -f mpegts /tmp/Serviio/transcoding-temp-535-MPEG2TS.stf

This produces a very watchable file via WMC7 from a remote share and perfect playing via the TV's usb drive.

it would seem that this matches the profile setting, with the fps set correctly (serviio sent -r 63.27 in this case according to the debug log), so is there something in the meta type translation I am missing perhaps? It would seem that the issue must be in the file type serviio is passing to the tv as the set is quite happy to play the file generated by that command with the extension changed to .ts

Any help would be great

Rick

[zip]

try transcoding into mpegPS instead of TS (use targetContainer="mpeg"). Regarding the frame rate, I'll file this as a bug

try transcoding into mpegPS instead of TS (use targetContainer="mpeg"). Regarding the frame rate, I'll file this as a bug

I did as suggested and it failed, I ran the passed command line (with fps fixed) manually and got a ton of buffer underflow errors. I changed the container back to mpegts and this time I manually ran the command and let it transcode a few min and stopped it, renamed the file to .ts, created a new directory and moved the file there and added the dir to serviio's library and forced a rescan then attempted to play the generated clip via serviio and it played perfectly. Is there a way for me to see what serviio is sending to the client in regards to meta information? Since no dlna client (except maybe wmp) understands what a wtv file is I want to make sure serviio is telling the client the file is a .ts file. That is the only thing I can think that might be going wrong since the file is clearly playable by the client even when served by serviio

Rick

[zip]

you can enable detailed logging and search for GET or HEAD requests. Those for the file will include DLNA protocol information and mime-type, like

Content-Type: video/x-matroska

I managed to filter out a lot of extra junk and I find this at each failure as well

2011-03-17 09:50:16,721 DEBUG [ResourceTransportRequestHandler] Unsupported range request, sending back 416
2011-03-17 09:50:16,721 DEBUG [ResourceTransportRequestHandler] HTTP/1.1 416 Requested Range Not Satisfiable, headers = [[Content-Type: video/mpeg]]

can I assume that servio is terminating the conversation and the LG is just showing me a generic oops! message? wtv is, BTW, the only format I have that actually needs to be transcoded everything else is sent as is.

I do not see the byte range that is requested, could it be that the client is asking for a range that is currently invalid because the transcoding has just started? Does serviio buffer up the file (wait before sending) a while?

Rick

[zip]

Alright, I remember now. This looks very much like a LG bug - basically transcoding doesn't work at these devices because they ask Serviio for byte range even though Serviio tell it it ca only do time based range for the (transcoded) file.

You'll see above in the log that the requested range is some ridiculous number.

You are right, the other devices are playing them now.

What would happen (I know nothing of the dlna protocol) if the LG asked for a byte range and you just sent it the next/first bytes? You say the transcoded files, it doesn't do this for files that do not need transcoded? I assume it does but you are handling that as expected and cannot send a byte range because the file is incomplete. It would be interesting to see what the device did if you ignored the request and just sent it what ever was next. Is this request the result of some kind of seek control state or ability that is sent to the client when they request content? If so is there a way to tell clients that are using an LG profile that the server does not support seeking?

Also, is it possible it is requesting the entire file and it is just overflowing the data type you are attempting to assgin it to? I would think a byte range for an entire 4.3GB file would end up as an odd negative if cast to an integer data type.

Rick

I just wanted to add that after playing around with the ffmpeg code a bit I am now able to just remux the wtv files and they play perfectly. They actually look better streaming through my samsung BDs than they do playing nativly (thanks to the BDs upscaling) and I added -async 1 to my ffmpeg wrapper and I am very happy all around. In fact if there was a way for me to track serviio's trancoding status (active/not active) I would remux everything (some of the ts and mkvs have the same audio sync issues I had with the wtv files originally). You migh consider a semaphore file or perhaps a txt file listing the child pids for everything serviio believes is transcoding. I noticed that ffmpeg can run until the end for some reason even when the client has ended and I don't know if serviio does any house keeping on partial files except on start up. I guess I could add a cron job to restart serviio a couple times a day when I know there is generally no one using it.

I believe I am about ready to make a donation, the wtv support is really a big push and many thanks. If only I could stream to the LG since that is the one in the MBR |-[

[zip]

I noticed that ffmpeg can run until the end for some reason even when the client has ended and I don't know if serviio does any house keeping on partial files except on start up.

It does on startup, tear down and when the same client requests another file to be transcoded - in that case the current transcode is stopped and the temp file removed.