Mailing List Archive: MythTV: Dev

Re: [mythtv-commits] mythtv branch master updated by cpinkham. v0.26-pre-894-gf66816d

Index | Next | Previous | View Threaded

gnassas at mac

Jul 16, 2012, 9:29 AM

Post #1 of 9 (536 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by cpinkham. v0.26-pre-894-gf66816d

On 2012-07-16, at 12:57 AM, Git Repo Owner wrote:

> commit f66816d5c7c2af13bc97986674b855021d9105a6
> Author: Chris Pinkham <cpinkham [at] mythtv> at Sun, 15 Jul 2012 21:51:26 -0700
> Committer: Chris Pinkham <cpinkham [at] mythtv> at Sun, 15 Jul 2012 21:51:26 -0700
> URL: http://code.mythtv.org/cgit/mythtv/commit/?id=f66816d5c7c2af13bc97986674b855021d9105a6
>
> HLS encoder enhancements.
> - Use AAC audio instead of MP3. This negates the need for
> using --enable-libmp3lame on the command line since we now use the
> built in AAC encoder in libavcodec. This change also requires
> converting the audio data to float for use by the encoder. For
> now, this commit uses C code to do the int to float conversion,
> but a call to use AudioOutputUtil::toFloat() to use assembler to
> do this conversion should be enabled in the near future.

I just built this and I'm getting "CoreContext transcode.cpp:1140 (TranscodeFile) - avfw->Init() failed". The full log is at:

http://files.nassas.com/mythtranscode.20120716155739.7970.log
http://files.nassas.com/mythtranscode.20120716155739.7970.ffmpeg

the second file is an ffmpeg -i from the source recording in case that's interesting. It's from an atsc broadcast.

About the stuttering problem I was seeing earlier - I wonder if it's due to a mismatch between the declared segment length in the .m3u8 file and the actual length of the .ts clip. When watching a 1 hour recording I find that the progress bar gets to its 60 minute endpoint when the playback is actually around the 50 minute mark. That would happen if each .ts was actually 9.x seconds.

The reason I tie the two together is with the stuttering audio I find I can get it to correct itself by jumping back and forth in the stream a few times. A passage that stuttered the first time through will suddenly play OK. So, it looks like the audio is basically fine but the way it's being interpreted is wonky. I may be wrong but it sounds like a good theory.

- George

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

cpinkham at bc2va

Jul 16, 2012, 12:29 PM

Post #2 of 9 (511 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by cpinkham. v0.26-pre-894-gf66816d [In reply to]

* On Mon Jul 16, 2012 at 12:29:46PM -0400, George Nassas wrote:
> I just built this and I'm getting "CoreContext transcode.cpp:1140 (TranscodeFile) - avfw->Init() failed". The full log is at:
>
> http://files.nassas.com/mythtranscode.20120716155739.7970.log
> http://files.nassas.com/mythtranscode.20120716155739.7970.ffmpeg

Can you run with "-v record,libav --loglevel debug" to get some
more detailed logging out of AVFormatWriter to see why it is
failing to init?

> About the stuttering problem I was seeing earlier - I wonder if it's
> due to a mismatch between the declared segment length in the .m3u8 file
> and the actual length of the .ts clip. When watching a 1 hour recording
> I find that the progress bar gets to its 60 minute endpoint when the
> playback is actually around the 50 minute mark. That would happen if
> each .ts was actually 9.x seconds.

This might be true, I haven't had a chance to debug this fully yet.
The segments should be >= 10.0 seconds because we split at the next
keyframe after the desired time. Can you check one of your .ts files
to see how long it actually is?

--
Chris
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

jyavenard at gmail

Jul 16, 2012, 3:23 PM

Post #3 of 9 (516 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by cpinkham. v0.26-pre-894-gf66816d [In reply to]

Hi

On Tuesday, 17 July 2012, George Nassas wrote:.
>
>
> About the stuttering problem I was seeing earlier - I wonder if it's due
> to a mismatch between the declared segment length in the .m3u8 file and the
> actual length of the .ts clip. When watching a 1 hour recording I find that
> the progress bar gets to its 60 minute endpoint when the playback is
> actually around the 50 minute mark. That would happen if each .ts was
> actually 9.x seconds.
>
>
Don't know about that encoding in particular but I do know about HLS
standard having read it many times and writing a decoder.
The segment size indicated in the m3u8 is the maximum size that should be
seen in the entire stream. There is no hard requirements that all segment
sizes should be the same , just that they shouldn't exceed the maximum
segment size. And even that spec isn't always compiled with as I've seen
plenty of live streams using any sizes.

At the end of the day, the HLS stream is just a mpeg-ts stream, and if
you're seeing an AV sync issue, the problem is in the mpeg-ts container and
not the HLS which has nothing to do with AV sync.

If you're using master, there's a way to rebuild the original mpeg-ts
stream from the HLS one, providing the actual mpeg-ts stream would be
easier to track why there's an AV sync issue.

gnassas at mac

Jul 16, 2012, 7:39 PM

Post #4 of 9 (511 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by cpinkham. v0.26-pre-894-gf66816d [In reply to]

On 2012-07-16, at 6:23 PM, Jean-Yves Avenard <jyavenard [at] gmail> wrote:

> If you're using master, there's a way to rebuild the original mpeg-ts stream from the HLS one, providing the actual mpeg-ts stream would be easier to track why there's an AV sync issue.

A couple of days ago I posted this:

> Here's a 1 minute clip from a morning show that has the problem for me:
>
> http://files.nassas.com/6021_20120713130343.mpg
> http://files.nassas.com/6021_20120713130343.xml
> http://files.nassas.com/6021_20120713130343.stream.zip
>
> That's the original file (100MB), the xml from /Content/GetLiveStreamList, and a zip of the resulting stream files (10MB).

The stream zip is from before Chis did the ac3 audio commit.

- George

gnassas at mac

Jul 16, 2012, 8:59 PM

Post #5 of 9 (510 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by cpinkham. v0.26-pre-894-gf66816d [In reply to]

On 2012-07-16, at 3:29 PM, Chris Pinkham wrote:

> Can you run with "-v record,libav --loglevel debug" to get some
> more detailed logging out of AVFormatWriter to see why it is
> failing to init?

http://files.nassas.com/mythtranscode.20120717025855.24663.log
http://files.nassas.com/mythtranscode.20120717025855.24663.xml

The second one is from /Content/GetLiveStreamList in case you're interested in the input parameters.

BTW, the transcode program doesn't change the job status to stopped or failed on the way out. It stays at "Starting" status forever.

>> About the stuttering problem I was seeing earlier - I wonder if it's
>> due to a mismatch between the declared segment length in the .m3u8 file
>
> This might be true, I haven't had a chance to debug this fully yet.
> The segments should be >= 10.0 seconds because we split at the next
> keyframe after the desired time. Can you check one of your .ts files
> to see how long it actually is?

For fun I ran ffmpeg against all of my .ts files. It turns out there are 30,330 of them belonging to the 52 streams I have queued up to watch. Here are occurrence counts for the most common segment durations:

7429 00:00:11.52
4560 00:00:12.00
2309 00:00:02.97
2291 00:00:11.97
2290 00:00:11.99

however they go up as long as 15 seconds and in one case 28.77.

In light of what JYA said about the m3u8 target duration being a max I guess the .ts writer should buffer until it knows the next keyframe will fit inside that max duration. I say that without having the slightest clue of how much effort it would be to code so don't take it as a feature request or anything.

- George

jyavenard at gmail

Jul 16, 2012, 11:57 PM

Post #6 of 9 (503 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by cpinkham. v0.26-pre-894-gf66816d [In reply to]

On 17 July 2012 13:59, George Nassas <gnassas [at] mac> wrote:
> In light of what JYA said about the m3u8 target duration being a max I guess
> the .ts writer should buffer until it knows the next keyframe will fit
> inside that max duration. I say that without having the slightest clue of
> how much effort it would be to code so don't take it as a feature request or
> anything.

It should make no difference for playback that a TS packet has a
keyframe or not.
The HLS player reconstitute when playing the original mpleg-ts, and
how it was first cut makes no difference.

It would slow down seeking, but that's pretty much it
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

cpinkham at bc2va

Jul 17, 2012, 8:54 PM

Post #7 of 9 (492 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by cpinkham. v0.26-pre-894-gf66816d [In reply to]

* On Mon Jul 16, 2012 at 12:29:46PM -0400, George Nassas wrote:
> About the stuttering problem I was seeing earlier

I'm pretty sure this is due to another bug I found in the same
commit, on the line above the one I already fixed related to
time timecode calculations.

I have a patch that fixes two issues in the current code. I'm
just trying to track down one final issue with A/V sync. The
timecodes are a bit off. I think this is mainly due to the
buffered video frames in the x264 encoder and now I'm a little
off in the other direction so I'm trying to track that down
tonight.

--
Chris
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

cpinkham at bc2va

Jul 17, 2012, 9:00 PM

Post #8 of 9 (493 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by cpinkham. v0.26-pre-894-gf66816d [In reply to]

* On Mon Jul 16, 2012 at 11:59:10PM -0400, George Nassas wrote:
> For fun I ran ffmpeg against all of my .ts files. It turns out there are 30,330 of them belonging to the 52 streams I have queued up to watch. Here are occurrence counts for the most common segment durations:
>
> 7429 00:00:11.52
> 4560 00:00:12.00
> 2309 00:00:02.97
> 2291 00:00:11.97
> 2290 00:00:11.99

Dod you script this? I'd like to run some tests here to test
this. I'm not sure what could be causing this right now. I've
noticed segments that vary in size by 50% or so, but didn't
think that the lengths were different, I figured it was the
encoding efficiency in some frames or sequences.

> In light of what JYA said about the m3u8 target duration being a
> max I guess the .ts writer should buffer until it knows the next
> keyframe will fit inside that max duration. I say that without
> having the slightest clue of how much effort it would be to code
> so don't take it as a feature request or anything.

It's not the next keyframe that needs to fit, it's everything
after the next keyframe since the segments should start on a
keyframe so you can 'seek' to any given segment and immediately
start playing frames without having to decode X amount of frames
before being able to display video. Currently the code splits
off another segment when it detects we've been more than 10 seconds
and the next frame is a keyframe. That's why I'm not sure you're
seeing what you're seeing, but then I haven't looked at the code
yet because I'm trying to figure out the audio issue first.

--
Chris
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

gnassas at mac

Jul 17, 2012, 9:47 PM

Post #9 of 9 (494 views)
Permalink

Re: [mythtv-commits] mythtv branch master updated by cpinkham. v0.26-pre-894-gf66816d [In reply to]

On 2012-07-18, at 12:00 AM, Chris Pinkham wrote:

> * On Mon Jul 16, 2012 at 11:59:10PM -0400, George Nassas wrote:
>> For fun I ran ffmpeg against all of my .ts files. It turns out there are 30,330 of them belonging to the 52 streams I have queued up to watch. Here are occurrence counts for the most common segment durations:
>>
>> 7429 00:00:11.52
>> 4560 00:00:12.00
>> 2309 00:00:02.97
>> 2291 00:00:11.97
>> 2290 00:00:11.99
>
> Dod you script this? I'd like to run some tests here to test
> this. I'm not sure what could be causing this right now. I've
> noticed segments that vary in size by 50% or so, but didn't
> think that the lengths were different, I figured it was the
> encoding efficiency in some frames or sequences.

It was just a one-liner. All my media disks have a common root so I did a:

for TS in /disks/d?/streaming/*.ts; do
ffmpeg -i $TS
done 2> all.ffmpeg

and then grep for Duration & use cut to narrow the line down to just the time part. From there sort and uniq -c got me the counts.

At one time the different Unixes had limits on command length but 30,000 fully qualified filenames must have made one hell of a long line.

- George
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads