Transcoding LiveTV

[arrmo]

FYI, changed the default recording directory, and it works now! That's not so easy unfortunately, would be nice to have the string quoted on the command line. One other interesting tidbit, I tried just removing the space in the name (Recorded TV -> RecordedTV), but N-PVR seems to put the space back in when I select the folder. Not sure why.

Thanks!

[sub]

If you remind me tomorrow, I'll give you a patch that handles the spaces.

[arrmo]

Will do - thanks so much!

[arrmo]

Just a gentle reminder ... . Thanks!

[sub]

Try this one.

[arrmo]

Works great - thanks!!!

[snagglewest]

Sorry to drag up an old thread, but it's related I think.

I got this working great, had it streaming for over an hour on the cell phone tonight! I see Sub said there's 2 files, one in the live TV buffer and one in the recording directory were ffmpeg transcodes the file. I'm getting both files and it's streaming great but I'm getting orphaned files in both the recording directory and the live TV buffer directory. There was 1 left in the buffer directory and 6-7 in ther recorded_TV directory. Is there something I'm missing? I'm using the transcode string madas posted in post #42 and here's the entries from the config.xml that I think are pertinent:

--------------------------------
<RecordingDirectory>D:\recorded_TV\</RecordingDirectory>

<RecordingDirectoryTranslation>D:\buffer\</RecordingDirectoryTranslation>
<LiveTVBufferDirectory>D:\buffer\</LiveTVBufferDirectory>

<AllowRemoteAPI>true</AllowRemoteAPI>
<AllowRemoteTranscode>true</AllowRemoteTranscode>
<AllowRemoteStreaming>true</AllowRemoteStreaming>
<TranscodeExe>.\other\ffmpeg-20150921\bin\ffmpeg.exe</TranscodeExe>
<TranscodeArgs>-y -v 0 -i [SOURCE] -f mpegts -acodec ac3 -ab 96k -ar 44100 -ac 2 -s [RESOLUTION] -vcodec libx264 -b [BITRATE] -maxrate [BITRATE] -flags +loop -refs 1 -coder 0 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -bt 200k -bufsize 96K -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -level 30 -aspect [ASPECT] -g 30 -async 2 [TARGET]</TranscodeArgs>
--------------------------------------

Attached is the log. The latest stream starts at 2015-09-22 18:49:28.405 [DEBUG][21] StartStream(7421:ESPN-HD)

Also, I'm using the latest build of ffmpeg (20150921) and the latest version of Npvr downloaded today. I'm surmising the patch up stream is already included in the latest version???

On another note - I'm trying to stream to a android phone over 3g/4g so a smaller file size is a consideration. I was able to stream tonight with

http://serverip:8866/transcode?channel=1...itrate=900

but I got quite a few hiccups which I'm sure is due to the connection speed on the phone. Does anyone have a better <TranscodeArgs> or ideas to cut down on the data stream size? I'm not ffmpeg fluent... it might as well be Mandarin Chinese
[ATTACH=CONFIG]40911[/ATTACH]
Thanks

Snag

[madas]

Hi Snag,

Did you try just reducing the resolution and bitrate to a lower number?

probably I would start by just reducing the bitrate to like 500 or 600. Do this in the URL that you use to start the session.

M

[snagglewest]

I think my main problem is the marginal data stream on the cell phone with 3g. Changing the resolution to 480X320 got me to the point the stream would play reasonably well with a decent picture but with a few freezes here and there. At 720X406 it wouldn't hardly play, mostly frozen. I've tried changing the bitrate but 900 seems to be the only rate that actually plays. When I change to 500, 450, 400 etc the stream never starts. VLC tries, the cone keeps spinning, but never actually displays a picture or sound. I'm thinking the audio is stereo, maybe doping it to mono might help out reducing the data stream? It's a cell phone, mono audio would be fine if I can figure out how to make ffmpeg output mono audio. I think its the -ar 44100 but I can't seem to find the correct settings for mono. I've played around a bi trying different values but it doesn't seem to help any.

Any ideas?

[madas]

add -report to the command line and try it again with a lower bit rate. Then you can look for the ffmpeg***.log file and see why it doesn't like it.

For the audio (-ar) you can try reducing to around 11025. I believe this is analog telephone quality